E-Mail im Namen des Benutzers senden API

E-Mail-API

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

Wie OAuth 2.0-Berechtigungen die Erlaubnis senden
Gmail, Outlook und IMAP-Unterstützung
On-behalf-vs. transaktionale E-Mail-APIs
Senden über die vereinheitlichte Unipile-API
CRM, KI-Assistent und Anwendungsfälle im Support
Rechtliche Konformität und Benutzerberechtigungen
Probieren Sie die Unipile E-Mail-API aus Lies die Dokumentation
Gesendet aus dem Postfach des Benutzers Echte Absenderadresse
Unipile E-Mail-API
Gesendet im Namen von POST
POST /api/v1/emails
200 OK
GET /api/v1/emails/{id}
200 OK
GET /api/v1/konten/{id}
200 OK
JSON-Nutzlast
{ "Konto_ID": "bennutzer_abc123", "zu": [{ "Kennung": "prospect@acme.com" }], "Betreff": "Nachverfolgung", "Körper": "Hallo Sarah..." }
OAuth 2.0 gesichert Benutzer erteilt Erlaubnis
E-Mail-Integration aufbauen?

Lesen Sie unseren Vollständiger Leitfaden zur E-Mail-API – OAuth-Flows, Synchronisation, Senden und Anbietervergleich.

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.

CRM Anwendungsfall

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.

E-Mail-Threads bleiben im gesendeten Ordner des Sachbearbeiters, wodurch die Historie an einem Ort erhalten bleibt.
Antworten landen im Posteingang des Sachbearbeiters für eine natürliche Gesprächskontinuität
Die Absenderreputation ist an die Domain des Absenders gebunden, nicht an eine gemeinsam genutzte Plattformdomain
KI-Assistent Anwendungsfall

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.

Entwurf genehmigt: Ein API-Aufruf versendet es von der tatsächlichen Adresse des Benutzers
Funktioniert, egal ob der Benutzer Gmail, Outlook oder einen beliebigen IMAP-Anbieter verwendet
Unterstützt Threading über den reply_to-Parameter, um Konversationen intakt zu halten
Support-Tool-Anwendungsfall

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.

Gemeinsames Postfach einmal verknüpft, für alle autorisierten Agenten zugänglich
Antworten zeigen immer die korrekte Unternehmensdomain im Feld "Von" an
Anhänge, CC und BCC werden alle über denselben einheitlichen Endpunkt unterstützt
Bessere Zustellbarkeit
Von der eigenen Domain des Benutzers gesendete E-Mails bestehen SPF- und DKIM-Prüfungen, die mit seinem Konto und nicht mit einem gemeinsamen Absender verknüpft sind.
OAuth-gesicherter Zugriff
Nutzer erteilen die Erlaubnis über den OAuth-Flow ihres Anbieters. Keine Passwörter gespeichert, jederzeit vollständig widerrufbar.
Eine einheitliche API
Dasselbe POST /api/v1/emails Der Endpunkt unterstützt Gmail-, Outlook- und IMAP-Konten.
Kürzere Markteinführungszeit
Überspringen Sie den Aufbau separater Integrationen für Gmail, Outlook und IMAP. Unipile normalisiert alle drei hinter einer einzigen Schnittstelle.
Die Kernbotschaft: Ihre Nutzer haben bereits E-Mail-Adressen, denen ihre Kontakte vertrauen. On-behalf Sending ermöglicht es Ihrer SaaS, dieses Vertrauen zu nutzen, ohne dass jemand den Anbieter wechseln oder ein neues Postfach erstellen muss. Für ein umfassenderes Bild, wie E-Mail-APIs funktionieren, siehe die E-Mail-API-Leitfaden.
Kostenlos mit dem Erstellen beginnen

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.

1

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.

Für IMAP-Anbieter gibt der Benutzer sein app-spezifisches Passwort oder seine IMAP-Zugangsdaten direkt in ein von Unipile gehostetes Formular ein. Unipile speichert die Zugangsdaten verschlüsselt und verwaltet die automatische Wiederverbindung.
2

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.

Unipile handhabt Token-Aktualisierungen automatisch. Wenn ein Gmail- oder Outlook-Token abläuft, erneuert Unipile ihn im Hintergrund, sodass Ihre Sendeanfragen aufgrund abgelaufener Anmeldeinformationen niemals fehlschlagen.
3

Ü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".

Der gleiche API-Aufruf funktioniert unabhängig vom Anbieter. Sie schreiben eine Integration; Unipile übersetzt sie transparent in die Gmail API, Microsoft Graph oder SMTP.

Code-Beispiele

Python
Node.js
Python - E-Mail im Namen des Benutzers senden
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": "..."}
Node.js - E-Mail im Namen des Benutzers senden
// 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.

Kriterien
Im Auftrag (Unipile)
Transaktionsbasiert (SendGrid, etc.)
Von Adresse
Die echte E-Mail-Adresse des Benutzers
Die Domain Ihrer Plattform
Zustellbarkeit
SPF/DKIM-Reputation des Benutzers
Gemeinsame IP-Reputation des Absenders
Benötigte Zustimmung des Nutzers
Ja – OAuth 2.0- oder IMAP-Anmeldeinformationen
Nein – die Plattform besitzt den Absender
Gesendete Ordnerverfolgung
Erscheint im Ordner "Gesendet" des Benutzers
Nein – separate Versandinfrastruktur
Antwort-Threading
Native Thread Continuity
Manuelle Workarounds für Message-IDs
Am besten für
CRM, KI-Assistenten, Support-Tools, Vertriebsautomatisierung
Passwort zurücksetzen, Quittungen, Marketingkampagnen, Benachrichtigungen
Anbietersupport
Google Mail, Outlook, IMAP
Anbieterunabhängiges SMTP
Wann welcher Ansatz verwendet werden soll
Verwenden Sie eine On-Behalf-API, wenn die Identität des Absenders für den Empfänger wichtig ist – z. B. für Vertriebsaktivitäten, personalisierte Nachfassen und Support-Antworten. Verwenden Sie eine Transaktions-API, wenn die Plattform der Absender ist – z. B. für Passwort-Resets, Rechnungen und Systembenachrichtigungen. Viele SaaS-Produkte benötigen beides: eine Transaktions-API für System-E-Mails und eine On-Behalf-API für benutzergesteuerte Nachrichten. Spezifische Implementierungsdetails für Gmail finden Sie unter Gmail API E-Mail senden Anleitung. Für Microsoft-Konten siehe die Outlook E-Mail-API Leitfaden.

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.

Bereit, den E-Mail-Versand im Auftrag zu Ihrem SaaS hinzuzufügen?
Kostenlose Testversion – keine Kreditkarte erforderlich. In weniger als 30 Minuten mit dem Versenden beginnen.
Lesen Sie den Leitfaden zur E-Mail-API
Unterstützte Anbieter
Google Mail
Google OAuth 2.0
Versand über die Gmail API - vollständige Thread-Unterstützung
Google Workspace-Konten werden unterstützt
Anhänge, CC, BCC, Antwort an
Automatisches Token-Refresh, gehandhabt von Unipile
Leitfaden zum Senden von E-Mails mit der Gmail API
Ausblick
Microsoft OAuth 2.0
Versendet über die Microsoft Graph API
Umfasst Outlook und Microsoft 365 persönlich
Exchange Online vollständig unterstützt
Anhänge, CC, BCC, Antwort an
Outlook E-Mail API-Leitfaden
IMAP
Universelle Fallback-Option
Versand per SMTP für jede IMAP-kompatible Mailbox
Beinhaltet Yahoo, Fastmail, ProtonMail (IMAP-Brücke) und mehr
Gleicher vereinheitlichter API-Endpunkt wie Gmail und Outlook
Anmeldeinformationen verschlüsselt gespeichert, niemals für Ihre App sichtbar
IMAP API-Leitfaden
So starten Sie in 4 Schritten
1 Erstellen Sie ein Unipile-Konto bei dashboard.unipile.com und holen Sie sich Ihre DSN und Ihren API-Schlüssel.
2 Erstelle einen gehosteten Auth-Link Unipile übernimmt den OAuth-Redirect zu Gmail oder Outlook oder zeigt das Formular für IMAP-Anmeldedaten an.
3 Speichere die account_id zurückgekehrt, nachdem der Benutzer den Vorgang abgeschlossen hat. Dies ist der stabile Bezeichner für alle zukünftigen Operationen auf diesem Postfach.
4 Rufe POST /api/v1/emails auf mit der account_id und der Nachrichten-Payload. Die E-Mail wird vom eigenen Postfach des Benutzers über die Infrastruktur seines Anbieters versendet.
On-Behalf E-Mail-Versand heute einrichten Lies die API-Dokumentation

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öglichthttps://mail.google.com/ oder die eingeschränkteren Gmail senden Umfang (falls Sie nur Sendeberechtigung benötigen)
  • Outlook / Microsoft 365: Microsoft Graph Mail.Senden Umfang, plus Mail.ReadWrite falls 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.

Sprechen Sie mit einem Experten
de_DEDE