LinkedIn
Instagram
Facebook
WhatsApp
Telegram
Google Kalender
Outlook-Kalender
Slack-Gemeinschaft beitretenE-Mails per API lesen: Ein Leitfaden für Entwickler über Posteingangszugriff
Umfang Diese Anleitung behandelt Synchronisierungs-APIs zum Lesen bestehender Posteingänge von Nutzern – Gmail API, Microsoft Graph, IMAP und vereinheitlichte Ebenen wie Unipile. Dies unterscheidet sich von transaktionalen Diensten (SendGrid, Mailgun), die ausgehende E-Mails von Ihrer Domain senden.
Produkte entwickeln, die Benutzer-E-Mails programmatisch lesen. Von einer einzigen GET /api/v1/emails Aufrufe von Webhooks in Echtzeit: Diese Anleitung behandelt jeden Ansatz mit funktionierendem Code in Node.js, Python und cURL.
// E-Mails mit einem einzigen einheitlichen API-Aufruf lesen
const response = await fetch(
'https://api3.unipile.com:PORT/api/v1/emails',
{
Kopfzeilen: {
'X-API-KEY': process.env.UNIPILE_API_KEY,
'Konto-ID': accountId
}
}
);
const { E-Mails } = await Antwort.json();
// Gleiche JSON-Struktur für Gmail, Outlook & IMAP
E-Mails.forEach(e-Mail => {
Konsole.log(email.betreff, email.von_teilnehmer);
});
Gmail, Outlook & IMAP
Was ist eine Read Email API?
Eine Read-Email-API ist eine HTTP-Schnittstelle, die es Ihrer Anwendung ermöglicht, E-Mails aus dem vorhandenen Postfach eines Benutzers abzurufen, herunterzuladen und zu verarbeiten – ohne Speicherung von Passwörtern oder Erstellung anbieterspezifischer Integrationen. Sie ist die Grundlage für jedes Produkt, das Sichtbarkeit im Posteingang benötigt: CRM-Synchronisierung, KI-gestützte E-Mail-Assistenten, Support-Automatisierung oder Archivierung zur Einhaltung von Vorschriften.
A E-Mail-API lesen ermöglicht Endpunkte zur Authentifizierung gegen das E-Mail-Postfach eines Benutzers (über OAuth 2.0 oder IMAP-Zugangsdaten), zum Auflisten von Posteingangsnachrichten, zum Abrufen vollständiger E-Mail-Texte mit Anhängen und zum Abonnieren von Echtzeit-Zustellungsereignissen. Es arbeitet mit dem bestehenden Gmail-, Outlook- oder IMAP-Konto des Benutzers – nicht eine Domäne, die Sie kontrollieren. Dies unterscheidet sie von Transaktions-E-Mail-APIs (SendGrid, Mailgun, Resend), die ausgehende E-Mails im Namen Ihrer Anwendung versenden.
Verbinden Sie sich mit den bestehenden Postfächern der Nutzer. E-Mails in Echtzeit lesen, synchronisieren und darauf reagieren. Authentifizierung über OAuth 2.0 oder IMAP. Der Nutzer gewährt Zugriff auf sein eigenes Postfach.
Ausgehende E-Mails von einer Domain, die Ihnen gehört, versenden. Wird für Quittungen, Benachrichtigungen, Passwort-Zurücksetzungen verwendet. Kein Posteingangszugriff.
Warum das programmgesteuerte Lesen von E-Mails wichtig ist
Die Möglichkeit, E-Mails von Benutzern über eine API zu lesen, eröffnet eine Produktkategorie, die mit SMTP allein einfach unmöglich war. Hier sind die vier primären Anwendungsfälle, die die Akzeptanz im Jahr 2026 vorantreiben.
CRM und Sales Engagement Synchronisation
Vertriebstools müssen jede E-Mail-Konversation zwischen einem Vertriebsmitarbeiter und einem Interessenten sehen – automatisch, ohne manuelles Protokollieren. Eine Read-Email-API zieht Unterhaltungen direkt aus dem Posteingang des Vertriebsmitarbeiters und synchronisiert sie in Echtzeit mit Ihrem CRM.
KI-Agenten und E-Mail-Copiloten
Große Sprachmodelle benötigen Kontext. Indem Sie Ihrem KI-Agenten einen Echtzeitstrom von E-Mail-Nachrichten zuführen, können Sie Copiloten erstellen, die automatisch Antworten entwerfen, E-Mail-Threads zusammenfassen, Aktionspunkte extrahieren und Konversationen priorisieren.
Kundensupport-Automatisierung
Support-Teams erhalten täglich Tausende von E-Mails. Eine Read Email API ermöglicht es Ihrer Plattform, eingehende Anfragen zu klassifizieren, an die richtige Warteschlange weiterzuleiten und automatisierte Antworten auszulösen – und das alles, bevor ein Mensch ein Ticket öffnet.
Compliance, Archivierung und eDiscovery
Regulierte Branchen müssen jede E-Mail aufbewahren und indizieren. Eine API für gelesene E-Mails bietet den programmatischen Zugriff, der erforderlich ist, um Posteingänge kontinuierlich zu archivieren, Richtlinienverstöße zu kennzeichnen und E-Mail-Aufzeichnungen bei Bedarf für rechtliche Überprüfungen zu produzieren.
Native APIs zum Lesen von E-Mails: Gmail, Outlook und IMAP
Jeder große E-Mail-Anbieter bietet seine eigene Lese-API mit unterschiedlichen Endpunkten, Authentifizierungsmodellen und Funktionen an. So sieht das jeweils in der Praxis aus.
Gmail-API
OAuth 2.0Die Gmail API ist eine REST-API, die auf Googles Infrastruktur aufbaut. Sie verwendet users.messages.list um eine Mailbox zu paginieren und Benutzer.Nachrichten.Abrufen um eine vollständige Nachricht abzurufen. Es unterstützt Push-Benachrichtigungen über Google Pub/Sub, was eine Echtzeit-Posteingangsüberwachung ohne Abfragen ermöglicht. Ratenbegrenzung: 250 Quoten-Einheiten pro Benutzer pro Sekunde. Hinweis: Gmail erfordert OAuth 2.0 - API-Schlüssel funktionieren nicht für den Postzugang. Siehe Warum Gmail API-Schlüssel ablehnt.
# Nachrichten im Posteingang auflisten (Gmail-API)
locken. -X GET \
"https://gmail.googleapis.com/gmail/v1/users/me/messages?labelIds=INBOX&maxResults=20" \
-H "Berechtigung: Träger ACCESS_TOKEN"
# Eine einzelne E-Mail mit dem vollständigen Text abrufen
locken. -X GET \
"https://gmail.googleapis.com/gmail/v1/users/me/messages/MESSAGE_ID?format=full" \
-H "Berechtigung: Träger ACCESS_TOKEN"
Microsoft Graph (Outlook und Microsoft 365)
OAuth 2.0Microsoft Graph ist die einheitliche API für alle Microsoft 365-Dienste, einschließlich persönlicher Outlook-Konten, Exchange Online und Microsoft 365-Geschäftspostfächer. /ich/nachrichten Endpunkt gibt Nachrichten mit vollständigem Body-Inhalt in einer einzigen Anfrage zurück. Paginierung verwendet $skip und $oben OData-Parameter. Sehen Sie sich das vollständige Microsoft Graph E-Mail-Integrationshandbuch für Details.
# Nachrichten im Posteingang auflisten (Microsoft Graph)
locken. -X GET \
""https://graph.microsoft.com/v1.0/me/messages?\$top=20&\$filter=parentFolderId eq 'inbox'"' \
-H "Berechtigung: Träger ACCESS_TOKEN" \
-H "Content-Type: application/json"
# Eine einzelne Nachricht mit Text abrufen
locken. -X GET \
"https://graph.microsoft.com/v1.0/me/messages/MESSAGE_ID?\$select=subject,body,from,receivedDateTime" \
-H "Berechtigung: Träger ACCESS_TOKEN"$auswählen und Akzeptieren Kopfzeilen.
IMAP
Universelles ProtokollIMAP (Internet Message Access Protocol) ist das universelle E-Mail-Protokoll, das von praktisch jedem Mailserver unterstützt wird. Es ist keine REST-API, sondern eine zustandsbehaftete TCP-Verbindung über Port 993 (TLS). Sie geben Befehle wie HOLEN, SUCHENund IDLE über die Verbindung. Für eine tiefere Betrachtung siehe unser IMAP API Integrationshandbuch.
import imaplib, E-Mail
# Verbinden und authentifizieren
E-Mail = imaplib.IMAP4_SSL('imap.example.com')
Post.Anmelden('user@example.com', 'App-Passwort')
Post.Auswählen('POSTeingang')
# Suche nach verborgenen Botschaften
Status, Nachrichten-IDs = Post.Suche(Nichts, 'UNGESEHEN')
für msg_id in Nachrichten_IDs[0].trennen():
_, Daten = Post.fetch(msg_id, '(RFC822)')
Nachricht = E-Mail.Nachricht_von_Bytes(Daten[0][1])
print(Nachricht['Betreff'], Nachricht['von'])IDLE Befehl, der eine Verbindung offen hält und auf Serverbenachrichtigungen wartet. Dies lässt sich nicht einfach über einige hundert gleichzeitige Konten hinaus skalieren.Yahoo Mail, ProtonMail, Zoho und andere Anbieter unterstützen IMAP als universelle Rückfalloption, sodass sie durch den oben genannten IMAP-Ansatz abgedeckt sind. Einige (wie Yahoo) bieten auch begrenzte proprietäre APIs an, aber keine erreicht die Fähigkeiten der Gmail API oder von Microsoft Graph. Für die meisten Produkte, die mehrere Anbieter unterstützen, ist IMAP die universelle Rückfalloption für alle Postfächer, die nicht von Gmail oder Outlook OAuth abgedeckt sind. A Vereinheitlichte E-Mail-API führt diese Verhandlung automatisch durch.
Die verborgene Komplexität des Lesens von E-Mails in großem Maßstab
Das Erstellen einer API-Integration zum Lesen von E-Mails für einen einzelnen Anbieter für eine Demo dauert einen Nachmittag. Das Erstellen einer, die bei Produktionsniveau zuverlässig für alle Anbieter funktioniert, ist eine ganz andere Herausforderung. Hier ist, was die technische Entwicklung tatsächlich beinhaltet.
OAuth-Flow pro Anbieter
Jeder Anbieter hat seine eigene OAuth 2.0-Implementierung, Anforderungen an den Zustimmungsbildschirm, Scopes und den Token-Lebenszyklus. Die Unterstützung von Gmail und Outlook bedeutet, zwei separate OAuth-Apps, zwei Entwicklerkonsolen, zwei Token-Aktualisierungsstrategien und zwei Sätze von Compliance-Anforderungen (Google CASA Tier 2, Microsoft Publisher Verification) zu pflegen.
Paginierungsunterschiede
Jeder Anbieter paginiert anders. Gmail verwendet undurchsichtige Seiten-Token. Microsoft Graph verwendet OData $skip und nächsterLink Cursorn. IMAP verwendet numerische UID-Bereiche. Die Implementierung einer konsistenten Paginierungsabstraktion für alle drei erfordert nicht triviale Adapter-Codes.
MIME-Parsing
E-Mails kommen als rohe MIME-Dokumente mit verschachtelten Multipart-Grenzen, Base64- oder Quoted-Printable-Kodierung, mehreren Zeichensätzen und Inline-Anhängen an. Gmail gibt Base64url-kodierte Teile zurück. IMAP gibt rohe RFC 822 zurück. Keines von beiden liefert Ihnen einen sauberen Plain-Text-Body, ohne den vollständigen MIME-Baum zu parsen.
Ratenbegrenzungen und Backoff
Gmail erzwingt 250 Quota-Einheiten pro Benutzer pro Sekunde (Auflistungen kosten 5 Einheiten, Abfragen kosten 5 Einheiten). Microsoft Graph drosselt bei 10.000 Anfragen pro 10 Minuten pro App pro Mandant. Beide geben 429-Fehler zurück, die exponentielles Backoff mit Jitter erfordern. Bei 1.000 verknüpften Konten wird die Verwaltung der Ratenbegrenzung zu einem vollständigen Ingenieurproblem.
Echtzeit: Webhooks vs. Polling vs. IDLE
Benachrichtigungen über eingehende E-Mails erfordern je nach Anbieter völlig unterschiedliche Mechanismen. Gmail verwendet Google Pub/Sub Push-Abonnements, die alle 7 Tage erneuert werden müssen. Microsoft Graph verwendet Änderungsbenachrichtigungsabonnements mit einer maximalen Lebensdauer von 4.230 Minuten. IMAP verwendet den IDLE-Befehl, der eine persistente TCP-Verbindung pro Konto offen hält.
Thread-Inkonsistenzen über Anbieter hinweg
Gmail gruppiert Nachrichten nativ in Threads. Microsoft Graph hat ein conversationId-Feld, aber Threads verhalten sich anders als bei Gmail. IMAP hat keine native Threadbildung – Sie rekonstruieren Threads manuell durch Abgleich der Referenzen und In-Reply-To-Header. Der Aufbau einer plattformübergreifenden einheitlichen Thread-Ansicht erfordert erhebliche Normalisierungslogik.
Lesen der E-Mail-API-Architektur: 3 Ansätze im Vergleich
Es gibt keine einzige "korrekte" Architektur für das Lesen von E-Mails. Der richtige Ansatz hängt davon ab, wie viele Anbieter Sie unterstützen müssen, von Ihrer Ingenieurskapazität und Ihren Skalierungsanforderungen. Hier ist ein ehrlicher Vergleich.
| Ansatz | Vorteile | Kons | Wann verwenden |
|---|---|---|---|
| Direkte Anbieter-APIs Gmail API, Microsoft Graph |
Kostenlose Stufe, voller Funktionszugriff, keine Zwischenlatenz | OAuth-Einrichtung pro Anbieter, MIME-Parsing, separate Ratenlimitverwaltung, keine bereichsübergreifende Normalisierung | Nur ein Anbeiter |
| Selbst gehostetes IMAP imaplib, node-imap |
Universelles Protokoll, funktioniert mit jedem Postfach, keine OAuth-App erforderlich | Stateful TCP-Verbindungen, keine Push-Benachrichtigungen (Polling oder IDLE), Verwaltung von Connection Pools, langsam bei Skalierung | Nur Legacy / On-Premise |
| Vereinheitlichte API zum Lesen von E-Mails Unipile |
Ein Endpunkt für alle Anbieter, normalisierte JSON-Antwort, verwaltetes OAuth, einheitliche Webhooks, integrierte Wiederholungslogik | Zusätzliche API-Aufrufkosten pro verknüpftem Konto, externe Abhängigkeit | Multi-Anbieter-Produkte |
Wenn jeder Nutzer Ihres Produkts Gmail verwendet, bauen Sie direkt gegen die Gmail API. Sie erhalten volle Funktionsparität, keine zusätzlichen Kosten und Zugriff auf Gmail-spezifische Funktionen wie Labels, Threads und Pub/Sub-Push.
Lokale Mailserver, Unternehmens-Exchange-Bereitstellungen ohne Zugriff auf die Graph-API oder Szenarien, in denen OAuth nicht verfügbar ist. Verwenden Sie IMAP als Fallback-Lösung, nicht als primäre Strategie für neue Produkte.
Wenn Ihre Benutzer Gmail-, Outlook- und IMAP-Postfächer haben und Sie eine einheitliche API für den E-Mail-Abruf über alle hinweg benötigen, eliminiert eine vereinheitlichte Schicht wie Unipile das Integrationsproblem mit mehreren Anbietern vollständig.
E-Mails lesen mit der Unified Read Email API von Unipile
Unipile abstrahiert die Gmail API, Microsoft Graph und IMAP hinter einer einzigen Read-Email-API. Ein OAuth-Flow, ein Endpunkt, eine normalisierte JSON-Form – unabhängig davon, bei welchem Anbieter sich das Postfach Ihres Benutzers befindet. Hier erfahren Sie, wie Sie Ihre erste Inbox in unter 5 Minuten auslesen.
Generieren Sie eine gehostete Authentifizierungs-URL von Ihrem Unipile-Dashboard. Senden Sie diesen Link an Ihren Benutzer – er durchläuft den OAuth-Zustimmungsablauf für seinen Anbieter (Gmail, Outlook oder IMAP-Zugangsdaten) auf der gehosteten Seite von Unipile. Keine OAuth-App-Einrichtung, keine Konfiguration von Umleitungs-URIs auf Ihrer Seite. Siehe die Leitfaden für eine einheitliche E-Mail-API für den vollständigen Authentifizierungsfluss.
# Erstellen Sie einen gehosteten Authentifizierungslink für Ihren Benutzer
locken. -X POST \
"https://api3.unipile.com:PORT/api/v1/hosted/accounts/link" \
-H "X-API-KEY: DEIN_API_SCHLÜSSEL" \
-H "Content-Type: application/json" \
-d '{"type":"EMAIL","name":"user@example.com","success_redirect_url":"https://yourapp.com/connected"}'
#-Antwort: { "url": "https://auth.unipile.com/..." }
# Senden Sie diese URL an Ihren Nutzer – dieser schließt den OAuth-Vorgang bei seinem Anbieter abSobald der Nutzer sein Konto verknüpft hat, rufen Sie den Endpunkt für E-Mails mit seiner account_id. Die Antwort ist identisch, unabhängig davon, ob die zugrunde liegende Mailbox Gmail, Outlook oder IMAP ist.
# E-Mails im Posteingang auflisten (funktioniert mit Gmail, Outlook und IMAP)
locken. -X GET \
"https://api3.unipile.com:PORT/api/v1/emails?account_id=ACCOUNT_ID&limit=50" \
-H "X-API-KEY: DEIN_API_SCHLÜSSEL"
# Nach Ordner filtern
locken. "?account_id=ACCOUNT_ID&ordner=POSTeingang&limit=50" -H "X-API-KEY: DEIN_API_SCHLÜSSEL"
# Nur ungelesene Nachrichten filtern
locken. "...?account_id=ACCOUNT_ID&ungelesen=true" -H "X-API-KEY: DEIN_API_SCHLÜSSEL"Rufe eine vollständige E-Mail anhand der ID ab. Unipile gibt ein dekodiertes, normalisiertes Objekt mit reinem Textkörper, HTML-Körper und Metadaten von Anhängen zurück – keine MIME-Analyse auf Ihrer Seite erforderlich.
# Eine einzelne E-Mail mit vollständigem Text und Anhängen abrufen
locken. -X GET \
"https://api3.unipile.com:PORT/api/v1/emails/EMAIL_ID" \
-H "X-API-KEY: DEIN_API_SCHLÜSSEL"
#-Antwortfelder (immer normalisiert):
# { "id", "Betreff", "Datum", "Absender", "Empfänger",
# "body", "body_plain", "attachments": [{ "id", "filename", "size" }] }Registrieren Sie einen Webhook-Endpunkt in Ihrem Unipile-Dashboard. Unipile abstrahiert Gmail Pub/Sub, Microsoft Graph-Änderungsbenachrichtigungen und IMAP IDLE zu einem einzigen email.empfangen Event. Keine Abonnementverlängerung, kein IDLE-Verbindungspool zur Verwaltung.
// Unipile ruft Ihren Endpunkt auf, wenn eine neue E-Mail eintrifft
// Gleiches Ereignis für Gmail-, Outlook- und IMAP-Benutzer
App.Beitrag('/webhooks/email', (req, res) => {
const { event, account_id, email_id } = req.body;
wenn (Ereignis === 'E-Mail empfangen') {
// Details der vollständigen E-Mail abrufen
Neue E-Mail verarbeiten(account_id, email_id);
}
res.Status senden(200);
});Der vollständige E-Mail-API-Leitfaden behandelt Authentifizierung, alle Endpunkte, Paginierung, Download von Anhängen, Sicherheit und Compliance im Detail.
E-Mails lesen: Codebeispiele nach Sprache
Produktionsreife Code-Snippets zum Auslesen von E-Mails mit der unify reading API von Unipile. Alle Beispiele lesen mit demselben Code aus Gmail-, Outlook- und IMAP-Konten.
import fetch from 'node-fetch';
const Basis = 'https://api3.unipile.com:PORT/api/v1';
const API-Schlüssel = process.env.UNIPILE_API_KEY!;
Schnittstelle E-Mail {
Sie Zeichenkette;
Thema: Zeichenkette;
Datum: Zeichenkette;
from_attendee: { display_name: Zeichenkette; Kennung: Zeichenkette };
body: Zeichenkette;
Körper_Text Zeichenkette;
Anhänge: { id: Zeichenkette; Dateiname: Zeichenkette; Größe: Nummer }[];
}
// Posteingang-E-Mails auflisten – funktioniert für Gmail, Outlook und IMAP
async function ListeE-Mails(Kontonummer: Zeichenkette, Grenze = 50) {
const res = await fetch(
`${BASE}/emails?account_id=${accountId}&limit;=${limit}&folder;=INBOX`,
{ Header:{ 'X-API-KEY': API_SCHLÜSSEL } }
);
const Daten = await res.json();
return Daten.Elemente als E-Mail[];
}
// Rufe eine einzelne E-Mail mit vollständigem Inhalt + Anhängen ab
async function E-Mail erhalten(E-Mail-Adresse: Zeichenkette) {
const res = await fetch(`${BASE}/emails/${emailId}`,
{ Header:{ 'X-API-KEY': API_SCHLÜSSEL } }
);
return await res.json() als E-Mail;
}
// Verwendung
const Emails = await ListeE-Mails('acc_01abc...');
E-Mails.forEach(e=>console.log(e.Betreff, e.von_Teilnehmer.Kennung));import Betriebssystem
import Anfragen
Basis = "https://api3.unipile.com:PORT/api/v1"
ÜBERSCHRIFTEN = {"X-API-KEY"os.environ["UNIPILE_API_SCHLÜSSEL"]}
def Liste-E-Mails(account_id: str, limit: int = 50) -> Liste:
"Inbox-E-Mails auflisten - funktioniert für Gmail, Outlook und IMAP."
Antwort = Anfragen.bekommen.(
f"{BASIS}/emails",
headers=HEADERS,
params={
"Konto_ID"Konto-ID,
"Grenze"Grenze,
"Ordner": "Posteingang",
},
)
bzw.raise_for_status()
return bzw.json()["Gegenstände"]
def E-Mail_abrufen(email_id: str) -> dict:
"""Eine einzelne E-Mail mit Inhalt und Anhängen abrufen."""
Antwort = Anfragen.bekommen.(f"{BASIS}/emails/{email_id}", Header=HEADER)
bzw.raise_for_status()
return bzw.json()
# Verwendung
Emails = Liste-E-Mails("acc_01abc...")
für E-Mail in E-Mails
print(E-Mail["Betreff", E-Mail["von_teilnehmer"]["Kennung"])
#: Vollständigen Text der ersten E-Mail abrufen
Voll = E-Mail_abrufen(E-Mails0]["id"])
printvoll"Nachricht"])Paket Haupt
import (
"encoding/json"
"fmt"
"net/http"
"Betriebssystem"
)
Typ E-Mail Struktur {
ID Zeichenkette `json:"id"`
Betreff Zeichenkette `json:"Betreff"`
Körperfläche Zeichenkette `json:"körper_klar"`
}
Typ ListResponse Struktur {
Artikel []E-Mail json:"items"
}
Funktion ListeE-Mails(accountID Zeichenkette) ([]E-Mail, Fehler) {
URL := "https://api3.unipile.com:PORT/api/v1/emails?account_id=" + KontoID
Erf., _ := http.NeueAnfrage("ERHALTEN", URL, Null)
req.Header.Set("X-API-KEY", os.Getenv("UNIPILE_API_SCHLÜSSEL"))
resp, err := http.DefaultClient.Do(Anf.)
wenn err != Null { return Null, Fehler }
aufschieben resp.Body.Schließen()
variabel Ergebnis ListResponse
json.Neuer Dekoder(resp.Körper).Entschlüsseln(&Ergebnis)
return result.Items, Null
}
Funktion Haupt() {
E-Mails, _ := ListeE-Mails("acc_01abc...")
für _, e := Reichweite E-Mails {
fmt.Println(Betreff)
}
}Echtzeit-E-Mail-Lesen: Webhooks vs. Polling
Zu wissen, wann eine neue E-Mail ankommt, ist genauso wichtig wie die Fähigkeit, sie zu lesen. Es gibt drei verfügbare Mechanismen, die jeweils bei Skalierung sehr unterschiedliche operative Eigenschaften aufweisen.
Abfrage
Ihre Anwendung ruft den Endpunkt "E-Mails auflisten" über einen Timer auf (alle 30 Sekunden, alle 5 Minuten). Dies ist einfach zu implementieren, verbraucht aber Kontingente, führt zu Latenz und skaliert nicht über eine Handvoll Konten hinaus.
Native Anbieter Webhooks
Gmail Pub/Sub und Microsoft Graph senden Änderungsbenachrichtigungen sofort an Ihren Server. Schnell und quota-effizient – erfordert aber separate Einrichtung, separate Erneuerungslogik und unterschiedliche Ereignisschemata.
Unipile Unified Webhooks
Unipile abstrahiert alle Provider-Push-Mechanismen hinter einem einzigen email.empfangen Ereignis. Ein Endpunkt empfängt Benachrichtigungen für Gmail, Outlook und IMAP-Konten gleichermaßen – mit automatischer Abonnementverlängerung, die intern gehandhabt wird.
Unter der Haube verwaltet Unipile Gmail Pub/Sub-Abonnements, Microsoft Graph-Änderungsbenachrichtigungsabonnements und IMAP IDLE-Verbindungen – pro verknüpftem Konto, automatisch verlängert. Ihre Anwendung registriert eine Webhook-URL und empfängt ein normalisiertes Ereignis, unabhängig vom zugrunde liegenden Anbieter.
Sicherheit und Compliance beim Lesen von Benutzer-E-Mails
Der Zugriff auf Benutzer-E-Mails birgt erhebliche Sicherheits- und rechtliche Verpflichtungen. Hier sind die vier Bereiche, die Sie abdecken müssen, bevor Sie eine Integration für das Auslesen von E-Mails in die Produktion überführen.
OAuth-Bereichsminimierung
Fordern Sie immer den minimalen OAuth-Bereich an, der erforderlich ist. Zum Lesen von E-Mails verwenden Sie Schreibgeschützte Bereiche Fordern Sie niemals Sende- oder Verfassungsberechtigungen an, wenn Ihre Anwendung nur Zugriff auf den Posteingang benötigt. Der schreibgeschützte Bereich von Gmail ist gmail.readonly. Das Microsoft Graph-Äquivalent ist Mail.Lesen. Breite Anfragen lösen strengere Überprüfungsprozesse von Google und Microsoft aus und verringern das Vertrauen der Nutzer auf dem Zustimmungsbildschirm.
Token-Speicherung: Bewährte Praktiken
OAuth-Zugriffstoken und Aktualisierungstoken sind Anmeldeinformationen. Speichern Sie sie verschlüsselt im Ruhezustand Verwenden Sie AES-256 oder ein Äquivalent, niemals im Klartext in Ihrer Datenbank. Rotieren Sie Verschlüsselungsschlüssel nach einem Zeitplan. Protokollieren Sie nie Token in Anwendungsprotokollen. Implementieren Sie die Token-Widerrufung, wenn ein Benutzer sein Konto trennt – rufen Sie den Widerrufsendepunkt des Anbieters auf, löschen Sie nicht einfach den Datenbankeintrag.
DSGVO und Datensitz
E-Mail-Bodies enthalten häufig personenbezogene Daten, die unter die DSGVO fallen. Sie müssen in Ihrer Datenschutzerklärung genau dokumentieren, welche E-Mail-Daten Sie sammeln, speichern, verarbeiten und wie lange. Implementieren Sie einen Datenlöschungsfluss, der den E-Mail-Inhalt bei Aufforderung zur Löschung durch einen Nutzer entfernt. Wenn Sie E-Mail-Inhalte in Ihrer eigenen Infrastruktur speichern, berücksichtigen Sie die Anforderungen an den Datensitz für EU-Kunden.
Google CASA und Microsoft Publisher Verifizierung
Anwendungen, die sensible Gmail-Berechtigungen anfordern (einschließlich gmail.readonly) muss Googles CASA Stufe 2 Sicherheitsüberprüfung, bevor Anwendungen über die Testgrenze von 100 Benutzern hinaus zugelassen werden. Microsoft verlangt die Verifizierung durch den Herausgeber für Apps, die bestimmte Graph-Berechtigungen anfordern. Beide Prozesse dauern Wochen – planen Sie entsprechend vor Ihrem Startdatum. Die Nutzung von Unipile übernimmt diese Zertifizierungen von der Plattformebene.
Unipile kümmert sich auf Plattformebene um die Gmail CASA Tier 2-Zertifizierung, die Microsoft Publisher-Verifizierung, die SOC 2 Typ II-Prüfung und die DSGVO-Datenverarbeitungsvereinbarungen. Auf Unipile basierende Produkte übernehmen diese Zertifizierungen, anstatt sie eigenständig abzuschließen.
Preise der Read Email API: Kostenlose Kontingente und Kostenmodelle
Die kostenlosen Tarife für native Anbieter-APIs sind bei geringer Nutzung großzügig, aber die versteckten Kosten treten auf, wenn Sie mehrere Anbieter unterstützen, Token-Aktualisierungen in großem Umfang verwalten oder Ratenbegrenzungsgrenzen erreichen müssen. Hier ist eine ehrliche Aufschlüsselung.
| Anbieter | Kostenlose Stufe | Kostenmodell | Ratenbegrenzung | Versteckte Kosten |
|---|---|---|---|---|
| Gmail-API | Kostenlos mit Quoten | Kontingenteinheiten pro Anfrage. Keine Abrechnung pro Konto | 250 Einheiten/Sek./Benutzer, 1 Mrd. Einheiten/Tag | CASA Tier 2 Überprüfung, MIME-Parsing, Logik zur Erneuerung von Pub/Sub |
| Microsoft Graph | Kostenlos mit Drosselung | Im Microsoft 365 Tenant enthalten. Keine Gebühr pro Anruf | 10.000 Anfragen/10 Min/App/Mandant | Publisher-Verifizierungsprozess, Abonnementerneuerung, Mandanten-OAuth-Apps |
| IMAP (selbst gehostet) | Freies Protokoll | Keine API-Kosten. Infrastrukturkosten für Verbindungspools | Anbieter-spezifisch, ~10-20 Verbindungen/Konto | Serverinfrastruktur, IDLE-Verbindungsverwaltung, kein Push-Support |
| Unipile | 7 Tage kostenlos testen | Pro verknüpftem Konto pro Monat. Siehe kostenlose E-Mail-API-Stufe | Intern verwaltet, integrierte Wiederholungslogik | API-Aufruf Kosten pro Konto – kompensiert durch wegfallende OAuth/MIME-Entwicklung |
Beginnen mit einer kostenlosen E-Mail-API? Die Gmail API und Microsoft Graph bieten beide kostenlosen Zugang innerhalb der Kontingentgrenzen. Unipile bietet eine 7-tägige Testversion ohne Kreditkartenangabe, die Gmail-, Outlook- und IMAP-Konten abdeckt.
Kostenlose Testversion startenHäufige Fallstricke beim Aufbau einer Read-Email-Integration
Das sind die Fehler, die immer wieder zu Produktionsvorfällen bei Teams führen, die ihre erste E-Mail-API-Integration für das Lesen von E-Mails implementieren. Lerne sie, bevor du auf sie triffst.
Gmails 250 Einheiten pro Sekunde pro Benutzer klingen großzügig, bis man 500 Konten hat und einen anfänglichen Posteingangsabgleich durchführen muss. Das Auflisten von 500 Nachrichten kostet 2.500 Einheiten; das Abrufen jeder vollständigen Nachricht kostet weitere 2.500. Anfängliche Abgleiche für große Postfächer können tägliche Quoten in Stunden aufbrauchen.
OAuth-Aktualisierungstoken laufen still ab – Google widerruft sie nach 6 Monaten Inaktivität, nach einer Passwortänderung oder wenn ein Nutzer den Zugriff in den Einstellungen seines Google-Kontos widerruft. Wenn Ihre Token-Aktualisierungslogik keinen 401-Fehler erkennt und ihn dem Nutzer anzeigt, wird Ihre Anwendung einfach keine E-Mails mehr lesen, ohne dass ein sichtbarer Fehler angezeigt wird.
zuletzt_synchronisiert_um Zeitstempel und Benachrichtigung, wenn diese Ihr erwartetes Synchronisierungsintervall überschreitet.Gmail-Labels und IMAP-Ordner sind keine äquivalenten Konzepte. Gmails INBOX Die Kennzeichnung umfasst keine Nachrichten, die archiviert wurden (aus dem Posteingang entfernt, aber nicht gelöscht). Der Posteingangsordner von Microsoft Graph unterscheidet zwischen dem fokussierten Posteingang und anderen Fensteraufteilungen, es sei denn, Sie fragen beide ab. Teams stellen häufig fest, dass ihnen 20–40% Nachrichten fehlen, weil sie falsche Annahmen bezüglich der Ordner getroffen haben.
ALLES Nachrichten (nicht nur Posteingang) und Filterung nach Datum auf Ihrer Seite.E-Mail-Nachrichten kommen in einer Vielzahl von Zeichenkodierungen an: UTF-8, ISO-8859-1, Windows-1252, Shift-JIS. Gmail gibt Teile zurück, die mit base64url kodiert sind. IMAP gibt Teile zurück, die mit quoted-printable kodiert sind. Das Dekodieren einer Kodierung als eine andere erzeugt korrupten Nachrichtentext, der in Ihrer lokalen Testumgebung unsichtbar ist (die wahrscheinlich nur ASCII-E-Mails sendet).
Content-Transfer-Encoding und neu in UTF-8 kodieren. Testen Sie speziell mit E-Mail-Inhalten, die reich an japanischen, arabischen und Emojis sind.Die Erstellung einer einheitlichen Thread-Ansicht für Gmail-, Outlook- und IMAP-Konten erfordert die Normalisierung von drei völlig unterschiedlichen Threading-Modellen. Gmail hat native Thread-IDs. Outlook hat Konversations-IDs, die sich anders verhalten. IMAP hat keinerlei natives Threading – Sie rekonstruieren Threads aus Nachrichten-ID, Referenzenund Antwort auf Header, die nicht immer vorhanden oder korrekt sind.
Read Email API – Häufig gestellte Fragen
Die häufigsten Fragen von Entwicklern, die ihre erste Integration einer API zum Lesen von E-Mails erstellen.
gmail.readonly Geltungsbereich, erhalten Sie ein Zugriffstoken über die OAuth-Zustimmung und rufen Sie dann auf GET /gmail/v1/users/me/messages um Nachrichten aufzulisten und GET /users/me/messages/{id}?format=full um einzelne E-Mails abzurufen. Nachrichten werden als Base64url-kodierte MIME-Teile zurückgegeben, die Sie dekodieren müssen.GET /api/v1/emails) das normalisierte JSON für Gmail-, Outlook- und IMAP-Konten gleichermaßen zurückgibt. Sie authentifizieren Benutzer einmal über einen gehosteten OAuth-Link, und Unipile übernimmt die anbieterspezifischen OAuth-Flows, das MIME-Parsing und die Echtzeit-Webhook-Abstraktion hinter einer einzigen konsistenten Schnittstelle. Sehen Sie sich unsere an E-Mail-API-Leitfaden für eine vollständige Referenz./nachrichten/{id}/anhänge. IMAP erfordert das Parsen des MIME-Baums, um Anhängenteile zu identifizieren. Mit Unipile sind Metadaten von Anhängen (Dateiname, Größe, MIME-Typ) in der E-Mail-Antwort enthalten und der Anhangsinhalt ist über einen dedizierten Endpunkt verfügbar – kein MIME-Parsing erforderlich.email.empfangen Webhook-Ereignis, das für Gmail-, Outlook- und IMAP-Konten ausgelöst wird, mit interner Verwaltung automatischer Abonnements.Erneut versuchen nach Header. Implementiere exponentielles Backoff mit Jitter für Produktionszuverlässigkeit. IMAP-Limits sind anbieterspezifisch, typischerweise 10-20 gleichzeitige Verbindungen pro Konto.