Was bedeutet "Send on Behalf" in der E-Mail-API?
Das Senden von E-Mails im Namen eines Benutzers bedeutet, dass Ihre Anwendung Nachrichten direkt aus dem eigenen Postfach des Benutzers versendet und nicht von einem gemeinsamen transaktionalen Absender. Der Empfänger sieht die tatsächliche E-Mail-Adresse des Benutzers im Feld "Von". Dies ist die Grundlage für jedes SaaS-Produkt, das E-Mails für seine Benutzer verwaltet.
Was Sie lernen werden
Warum SaaS-Produkte den Versand von E-Mails im Auftrag benötigen
Die meisten SaaS-Produkte, die mit E-Mails arbeiten, stehen irgendwann vor der gleichen Anforderung: Der Benutzer möchte, dass Nachrichten von seiner eigenen Adresse gesendet werden, nicht von einer generischen Plattformdomäne. Egal ob CRM, KI-Schreibassistent oder Support-Tool, sobald Ihr Produkt E-Mails im Auftrag von Benutzern versendet, benötigen Sie das Senden im Auftrag anderer. Hier ist, warum das wichtig ist – und wie die drei Hauptanwendungsfälle auf die API abgebildet werden.
Vertriebsmitarbeiter senden von ihrem echten Gmail oder Outlook
Im CRM-Kontext ist der Vertriebsmitarbeiter derjenige, der die Beziehung aufbaut. Wenn Ihre Plattform Folgeaktivitäten sendet, von noreply@yourcrm.com, sinkt die Zustellbarkeit und der Interessent ist verwirrt. Beim Senden im Auftrag ruft Ihre CRM-Software die Unipile-API über das verknüpfte Konto des Verkäufers auf. Jede E-Mail landet im Posteingang des Interessenten und zeigt die echte Adresse des Vertreters an.
KI entwirft und versendet aus dem Postfach des Benutzers
KI-E-Mail-Assistenten – egal, ob sie Antworten automatisch entwerfen, Folgeaktionen planen oder Threads zusammenfassen – benötigen Schreibzugriff auf das Postfach des Benutzers. Ohne "On-Behalf-Sending" kann die KI nur Vorschläge machen, sie kann nicht ausführen. Mit einem verknüpften Konto über die Unipile API kann Ihr Assistent die genehmigte Nachricht mit einem einzigen API-Aufruf direkt von der Gmail- oder Outlook-Adresse des Benutzers senden.
Support-Mitarbeiter antworten von einem gemeinsamen Support-Posteingang
Kundensupport-Plattformen leiten Tickets oft über ein gemeinsames Postfach wie support@company.com. Diese Inbox ist selbst eine Mailbox – sie muss als Konto verknüpft werden. Mit Unipile kann Ihre Plattform diese freigegebene Outlook- oder IMAP-Mailbox verbinden, sodass jeder Agent Antworten senden kann, die scheinbar direkt von der offiziellen Support-Adresse stammen und den gesamten Gesprächsverlauf beibehalten.
POST /api/v1/emails Der Endpunkt unterstützt Gmail-, Outlook- und IMAP-Konten.Wie die On-Behalf-E-Mail-API funktioniert (OAuth 2.0-Flow)
Das Senden von E-Mails im Namen eines Benutzers erfordert drei Dinge: die Zustimmung des Benutzers, ein gültiges Zugriffstoken und einen Sendeaufruf über die Infrastruktur des Anbieters. Hier ist, wie dieser Ablauf in der Praxis funktioniert und wie Unipile ihn zu einer einzigen einheitlichen API abstrahiert. Eine umfassendere technische Referenz zu Sendeendpunkten, Parametern und Anbieterunterschieden finden Sie in unserem vollständigen E-Mail-API-Leitfaden.
Benutzer erteilt OAuth-Berechtigung
Der Nutzer klickt in Ihrem SaaS-Produkt auf "E-Mail verbinden". Unipile leitet ihn zur OAuth-Zustimmungsseite seines Anbieters weiter – Google für Gmail-Nutzer, Microsoft für Outlook- und Microsoft 365-Nutzer. Der Nutzer meldet sich an und genehmigt die angeforderten Scopes, die die Möglichkeit beinhalten, E-Mails in seinem Namen zu versenden. Passwörter werden niemals mit Ihrer Anwendung geteilt.
Ihre App erhält eine verknüpfte Konto-ID
Sobald der Benutzer den OAuth-Flow abgeschlossen hat, speichert Unipile das Zugriffstoken sicher ab und gibt eine account_id in Ihrer Anwendung. Dies ist eine stabile Kennung für das verknüpfte Postfach des Benutzers. Sie speichern diese ID in Ihrer Datenbank gegen den Benutzereintrag. Alle nachfolgenden E-Mail-Vorgänge für diesen Benutzer beziehen sich auf diese account_id – Sie greifen niemals auf das rohe OAuth-Token zu.
Über die Infrastruktur des Anbieters senden
Wenn Ihre Anwendung eine E-Mail senden muss, ruft sie auf POST /api/v1/emails mit der account_id und der Nachrichtennutzlast. Unipile leitet die Anfrage über den richtigen Anbieter: Gmail API für Google-Konten, Microsoft Graph API für Outlook- und Microsoft 365-Konten und SMTP für IMAP-Konten. Die E-Mail wird vom eigenen Postfach des Benutzers versendet und erscheint in dessen Ordner "Gesendet".
Code-Beispiele
import Anfragen # account_id nach Abschluss des OAuth-Flows durch den Benutzer abgerufen UNIPILE_DSN = "https://api1.unipile.com:13301" ACCESS_TOKEN = "IHR_ACCESS_TOKEN" KONTO_ID = "user_account_id_from_db" Nutzlast = { "Konto_ID": ACCOUNT_ID, "zu": [{ "Anzeigename": "Sarah Connor", "Kennung": "sarah@acme.com" }], "Betreff": "Im Nachgang zu unserem Gespräch", "Körper": "Hallo Sarah, ich melde mich nochmals...
" Antwort = Requests.Beitrag( f"{UNIPILE_DSN}/api/v1/emails", json=payload, headers={"X-API-KEY": ACCESS_TOKEN} ) print(response.json()) # {"object": "EmailSent", "email_id": "..."}
// account_id nach Abschluss des OAuth-Flows abgerufen const UNIPILE_DSN = "https://api1.unipile.com:13301"; const ACCESS_TOKEN = "IHR_ACCESS_TOKEN"; const KONTO_ID = "user_account_id_from_db"; const Nutzlast = { account_id: ACCOUNT_ID, zu: [{ anzeige_name: "Sarah Connor", Kennung: "sarah@acme.com" }], Thema: "Im Nachgang zu unserem Gespräch", Körper: "Hallo Sarah, ich melde mich nochmals...
" }; const response = await fetch(`${UNIPILE_DSN}/api/v1/emails`, { Methode: "POST", Kopfzeilen: { "X-API-KEY"ACCESS_TOKEN, "Content-Type": "application/json" }, Körper: JSON.stringify(Nutzlast) }); const Daten = await Antwort.json(); console.log(Daten); // { object: "EmailGesendet", email_id: "..." }
On-Behalf-of vs. Transaktionale E-Mail-API: Der entscheidende Unterschied
Diese beiden Kategorien von E-Mail-APIs lösen grundlegend unterschiedliche Probleme. Sie zu verwechseln ist der häufigste Fehler, den Teams bei der Spezifikation einer E-Mail-Integration machen. Hier ist, wie sie in jeder relevanten Dimension verglichen werden.
On-Behalf-E-Mail-Versand mit Unipile aufbauen
Unipile bietet eine einzige, vereinheitlichte API, die Gmail, Outlook und IMAP hinter einer konsistenten Schnittstelle verbirgt. Sie erstellen eine einzige Integration – Unipile kümmert sich um provider-spezifische OAuth-Flows, Token-Aktualisierung, SMTP-Routing und Fehlerbehandlung für alle drei. Hier ist, was für jeden Provider verfügbar ist.
E-Mail im Namen des Benutzers senden API – FAQ
Häufige Fragen zum E-Mail-Versand im Namen von Unipile
Ja, vorausgesetzt, der Benutzer erteilt ausdrücklich die Erlaubnis. Das Senden von E-Mails im Auftrag eines anderen Nutzers basiert auf OAuth 2.0 (für Gmail und Outlook) oder der expliziten Weitergabe von Anmeldedaten (für IMAP). In beiden Fällen autorisiert der Benutzer Ihre Anwendung wissentlich, von seinem Postfach aus zu senden. Dies ist derselbe Mechanismus, der von jedem wichtigen E-Mail-Client und Produktivitätstool verwendet wird.
Die wichtigsten Compliance-Anforderungen sind:
- Der Benutzer muss aktiv zustimmen, bevor Sie etwas in seinem Namen senden
- Ihre Datenschutzrichtlinie muss offenlegen, dass Sie auf die E-Mails des Nutzers zugreifen und E-Mails von dessen Postfach senden.
- Der Benutzer muss den Zugriff jederzeit widerrufen können (OAuth-Widerruf oder Trennung des Kontos)
- Sie dürfen keine Inhalte senden, die gegen die Nutzungsbedingungen des Anbieters verstoßen (z. B. Spam)
Es ist nicht legal um von der Adresse einer Person ohne deren Zustimmung zu senden. Unipiles OAuth-basierter Verknüpfungsfluss stellt sicher, dass Sie immer die ausdrückliche Zustimmung des Benutzers haben, bevor eine Sendeoperation durchgeführt wird.
Der Empfänger sieht die eigene Domain des Benutzers im Von-Feld - nicht die Domain deiner Plattform. Das ist das Kernversprechen des Sendens im Auftrag. Wenn zum Beispiel ein Vertriebsmitarbeiter mit der Adresse john@acme.com hat ihr Gmail-Konto verknüpft, wird jede E-Mail, die über Ihr CRM über Unipile gesendet wird Von: john@acme.com.
Die E-Mail wird über den tatsächlichen E-Mail-Anbieter des Benutzers (Gmail API, Microsoft Graph oder SMTP) versendet, was bedeutet:
- SPF-Einträge werden bestanden, da die sendende IP-Adresse vom Benutzerdomäne autorisiert ist
- DKIM-Signaturen sind gültig, weil der Anbieter mit dem Domänenschlüssel des Benutzers signiert
- DMARC-Ausrichtung besteht aus denselben Gründen
Das ist im Grunde anders als bei einer transaktionalen API, bei der Sie von einer gemeinsam genutzten Infrastruktur senden und der Empfänger die Domain Ihrer Plattform sieht.
Die erforderlichen Bereiche hängen vom Anbieter ab. Unipile übernimmt den OAuth-Zustimmungsbildschirm automatisch – Ihre Benutzer sehen ein Standarddialogfeld für Berechtigungen von Google oder Microsoft. Die genauen angeforderten Bereiche sind:
- Gmail der Gmail API-Bereich, der das Senden von Nachrichten ermöglicht
https://mail.google.com/oder die eingeschränkterenGmail sendenUmfang (falls Sie nur Sendeberechtigung benötigen) - Outlook / Microsoft 365: Microsoft Graph
Mail.SendenUmfang, plusMail.ReadWritefalls Sie auch Ihre Inbox lesen oder synchronisieren müssen - IMAP: Der Benutzer gibt seinen IMAP-Hostnamen, Port, Benutzernamen und entweder sein Passwort oder ein App-spezifisches Passwort an (erforderlich für Konten mit aktivierter Zwei-Faktor-Authentifizierung).
Benutzer können diese Berechtigungen jederzeit in den Sicherheitseinstellungen ihres Google- oder Microsoft-Kontos widerrufen oder durch Trennen des verknüpften Kontos innerhalb Ihres Produkts.
Ja. Jede Mailbox, die über OAuth oder IMAP-Anmeldedaten authentifiziert werden kann, kann als Unipile-Konto verknüpft werden. Dazu gehören:
- Gemeinsame Postfächer in Microsoft 365 (z. B. support@company.com- verknüpft über ein Dienstkonto mit den korrekten delegierten Berechtigungen
- Google Workspace freigegebene Postfächer und Gruppenadressen mit eingerichteten "Senden als"-Berechtigungen
- Jeder E-Mail-Alias, der von einem IMAP-zugänglichen Postfach verwaltet wird
Sie können auch die Anzeigename im Von-Feld unter Verwendung der from Parameter in der API-Nutzlast, ohne die zugrunde liegende Absenderadresse zu ändern.
Unipile kümmert sich automatisch um die Aktualisierung von Tokens für Gmail- und Outlook-Konten. OAuth-Zugriffstokens laufen in der Regel nach einer Stunde ab, aber das Aktualisierungstoken ist langlebig. Wenn Unipile ein abgelaufenes Zugriffstoken vor einem Sendevorgang erkennt, fordert es stillschweigend ein neues mit dem gespeicherten Aktualisierungstoken an – Ihre Anwendung bekommt davon nichts mit und der Sendeaufruf gelingt wie gewohnt.
Die einzige Zeit, in der Sie den Benutzer zur erneuten Authentifizierung auffordern müssen, ist, wenn er manuell widerrufenen Zugriff aus ihren Google- oder Microsoft-Konto-Einstellungen. Unipile zeigt dies als eine Änderung des Kontostatus an, die Sie über Webhooks erkennen oder durch Abfragen des Endpunkts für das Konto ermitteln können.
Haben Sie noch Fragen? Unser Team ist für Sie da.