So lesen Sie E-Mails über eine API: Ein Leitfaden für Entwickler für den Posteingangszugriff (2026)

Entwicklerhandbuch 2026

E-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.

read_inbox.js
// 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); });
200 OK - 47 E-Mails abgerufen (Gmail + Outlook + IMAP)
Kompatibel mit: Google Mail Ausblick IMAP Gmail, Outlook & IMAP
Definition

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.

Kurze Definition

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.

Diese Anleitung behandelt
Synchronisations- / E-Mail-Lese-APIs

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.

Beispiele: Gmail API, Microsoft Graph, IMAP, Unipile
Nicht dieser Leitfaden
Transaktionale E-Mail-APIs

Ausgehende E-Mails von einer Domain, die Ihnen gehört, versenden. Wird für Quittungen, Benachrichtigungen, Passwort-Zurücksetzungen verwendet. Kein Posteingangszugriff.

Beispiele: SendGrid, Mailgun, Resend, Postmark
Anwendungsfälle

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.

E-Mail-Austausch automatisch in Kontaktdatensätze protokollieren
Deal-relevante Signale aus E-Mail-Threads extrahieren
Antwortabsicht erkennen und Pipeline-Phase aktualisieren

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.

Neue E-Mails an eine LLM-Verarbeitungspipeline streamen
Kontextbezogene Antwortentwürfe generieren
Aufgaben, Termine und Verpflichtungen aus Threads extrahieren

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.

Support-E-Mails nach Thema und Dringlichkeit klassifizieren
Weiterleitung an Agentenwarteschlangen basierend auf E-Mail-Inhalt
Automatische Antworten für häufige Anfragemuster auslösen

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.

Kontinuierliche Archivierung des Posteingangs für GDPR- / FINRA-Konformität
Richtlinienverstoßerkennung in Mitarbeiter-Postfächern
eDiscovery-Export auf Abruf für Legal Hold
Anbieter-Deep-Dive

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.0

Die 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, wodurch eine Echtzeit-Posteingangsüberwachung ohne Abfragen möglich ist. Ratenbegrenzung: 250 Quoten-Einheiten pro Benutzer pro Sekunde.

gmail_lesen.sh
# 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"
Anmerkung: Gmail gibt Nachrichten als Base64-kodierte MIME-Teile zurück. Sie müssen jeden Teil dekodieren und die Multipart-Grenzen selbst parsen, um den Plain-Text-Body, den HTML-Body und Anhänge zu extrahieren.

Microsoft Graph (Outlook und Microsoft 365)

OAuth 2.0

Microsoft 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.

graph_read.sh
# 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"
Anmerkung: Microsoft Graph drosselt bei 10.000 Anfragen pro 10 Minuten pro Anwendung pro Mandant. Der Inhalt des Körpers wird je nach Einstellung als HTML oder Text zurückgegeben. $auswählen und Akzeptieren Kopfzeilen.

IMAP

Universelles Protokoll

IMAP (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.

imap_read.py
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'])
Anmerkung: IMAP erfordert die Aufrechterhaltung langjähriger TCP-Verbindungen und die Verwaltung von Connection-Pools durch Sie selbst. Echtzeitlieferung verwendet die 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.
Und was ist mit Yahoo und anderen Anbietern?

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.

Ingenieurwissenschaftliche Realität

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.

01

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.

GmailGoogle Cloud Console-App, CASA Tier 2 für sensible Geltungsbereiche, 1-Stunden-Zugriffstoken
Outlook:Azure AD App-Registrierung, Publisher-Verifizierung, konfigurierbare Token-TTL
IMAP:App-Passwörter oder OAuth (Gmail IMAP verwendet denselben Google OAuth-Flow)
02

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.

GmailpageToken Cursor, max 500 Ergebnisse pro Seite
Graph@odata.nextLink-URL, Parameter $top/$skip
IMAP:UID FETCH Bereiche, CONDSTORE für inkrementelle Synchronisierung
03

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.

RisikoInternationale Zeichen, Emojis und RTL-Text führen zu Kodierungs-Randfällen, die den Inhalt des Bodens beschädigen
AnhängeMuss den MIME-Baum durchlaufen, um Content-Disposition: attachment Teile zu finden
04

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.

Gmail250 Quoten-Einheiten/Sek./Nutzer. Tägliche Obergrenze: 1 Milliarde Einheiten
Graph10.000 Anfragen / 10 Minuten / App / Mandant. Retry-After Header
IMAP:Anbieterspezifisch, typischerweise 10-20 gleichzeitige Verbindungen pro Konto
05

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.

GmailPub/Sub Push, 7 Tage Verfallszeit, erfordert Erneuerungszyklus
GraphÄnderungsbenachrichtigungen Abonnement, max. ~3 Tage Ablauf
IMAP:IDLE-Befehl, 1 persistente TCP-Verbindung pro Konto
06

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.

GmailThreadId, messages.list?labelIds=INBOX gibt Thread-Gruppen zurück
GraphconversationId, aber nicht gleichbedeutend mit Gmail-Threads
IMAP:Nachrichten-ID / Referenz-Header müssen manuell analysiert werden
Architektur

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
Direkte Anbieter-APIs
Gmail API, Microsoft Graph
Vorteile Kostenlose Stufe, voller Funktionszugriff, keine Zwischenlatenz
Kons OAuth-Einrichtung pro Anbieter, MIME-Parsing, separate Ratenlimitverwaltung, keine bereichsübergreifende Normalisierung
Wann verwenden Nur ein Anbeiter
Selbst gehostetes IMAP
imaplib, node-imap
Vorteile Universelles Protokoll, funktioniert mit jedem Postfach, keine OAuth-App erforderlich
Kons Stateful TCP-Verbindungen, keine Push-Benachrichtigungen (Polling oder IDLE), Verwaltung von Connection Pools, langsam bei Skalierung
Wann verwenden Nur Legacy / On-Premise
Vereinheitlichte API zum Lesen von E-Mails
Unipile
Vorteile Ein Endpunkt für alle Anbieter, normalisierte JSON-Antwort, verwaltetes OAuth, einheitliche Webhooks, integrierte Wiederholungslogik
Kons Zusätzliche API-Aufrufkosten pro verknüpftem Konto, externe Abhängigkeit
Wann verwenden Multi-Anbieter-Produkte
Am besten für einen einzelnen Anbieter
Direkter Anbieter-API

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.

Am besten für Altsysteme
Selbst gehostetes IMAP

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.

Am besten für SaaS-Produkte
Vereinheitlichte API zum Lesen von E-Mails

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.

5-Minuten-Einrichtung

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.

1
Einen Benutzer mit dem gehosteten Auth-Link authentifizieren

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.

auth_link.sh
# 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 ab
2
Posteingangs-E-Mails auflisten - GET /api/v1/emails

Sobald 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.

list_emails.sh
# 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"
200 OK - normalisiertes JSON, gleiche Struktur für alle Anbieter
3
Erhalten Sie eine einzelne E-Mail mit Text und Anhängen

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.

get_email.sh
# 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" }] }
4
Neue E-Mails in Echtzeit über Webhooks empfangen

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.

webhook_handler.js
// 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); });
Ein Webhook-Ereignis ersetzt Gmail Pub/Sub + Graph-Abonnements + IMAP IDLE
Möchten Sie die vollständige Integrationsreferenz?

Der vollständige E-Mail-API-Leitfaden behandelt Authentifizierung, alle Endpunkte, Paginierung, Download von Anhängen, Sicherheit und Compliance im Detail.

Lesen Sie den Leitfaden zur E-Mail-API
Code-Beispiele

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.

Node.js / TypeScript
Python
Los
readEmails.ts
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));
read_emails.py
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"])
read_emails.go
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) } }
Real-Time

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.

Vermeide im großen Stil

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.

Einfach – keine serverseitige Einrichtung
API-Kontingent proportional zu Accounts x Frequenz ausgeben
5-Minuten-Umfrage = 5-Minuten-Verzögerung der Benachrichtigung
Skaliert nicht über ca. 100 aktive Konten hinaus
Anbieterspezifisch

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.

Nahezu sofortige Lieferung (Sekunden)
Kontingenteffizient – nur bei neuen E-Mails ausgelöst
Gmail: Pub/Sub-Abonnement läuft alle 7 Tage ab
Diagramm: Abonnement maximal 3 Tage, muss erneuert werden
IMAP IDLE: 1 TCP-Verbindung pro Konto
Empfohlen

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.

Eine Webhook-URL für alle Anbieter
Automatische Erneuerung von Pub/Sub und Graphen
IMAP IDLE intern pro Konto verwaltet
Normalisierte Nutzlast – jedes Mal die gleichen Felder
Wie Unipile die Echtzeit-E-Mail-Zustellung abstrahiert

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.

Gmail Pub/Sub
+
Graph-Abonnements
+
IMAP IDLE
->
E-Mail.empfangen Ereignis
Sicherheit und Einhaltung von Vorschriften

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 Compliance-Zertifizierungen

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.

SOC 2 Typ II
Google CASA Stufe 2
GDPR-konform
OAuth 2.0 Nur-Lese-Bereiche
Preisgestaltung

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
Gmail-API
Kostenlos mit Quoten
Kostenmodell Kontingenteinheiten pro Anfrage. Keine Abrechnung pro Konto
Ratenbegrenzung 250 Einheiten/Sek./Benutzer, 1 Mrd. Einheiten/Tag
Versteckte Kosten CASA Tier 2 Überprüfung, MIME-Parsing, Logik zur Erneuerung von Pub/Sub
Microsoft Graph
Kostenlos mit Drosselung
Kostenmodell Im Microsoft 365 Tenant enthalten. Keine Gebühr pro Anruf
Ratenbegrenzung 10.000 Anfragen/10 Min/App/Mandant
Versteckte Kosten Publisher-Verifizierungsprozess, Abonnementerneuerung, Mandanten-OAuth-Apps
IMAP (selbst gehostet)
Freies Protokoll
Kostenmodell Keine API-Kosten. Infrastrukturkosten für Verbindungspools
Ratenbegrenzung Anbieter-spezifisch, ~10-20 Verbindungen/Konto
Versteckte Kosten Serverinfrastruktur, IDLE-Verbindungsverwaltung, kein Push-Support
Unipile
7 Tage kostenlos testen
Kostenmodell Pro verknüpftem Konto pro Monat. Siehe kostenlose E-Mail-API-Stufe
Ratenbegrenzung Intern verwaltet, integrierte Wiederholungslogik
Versteckte Kosten API-Aufruf Kosten pro Konto – kompensiert durch wegfallende OAuth/MIME-Entwicklung
Häufige Fehler

Hä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.

01
Kontingentüberschreitung bei Gmail in großem Maßstab

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.

Korrigieren: Implementieren Sie exponentielles Backoff bei 429-Antworten, priorisieren Sie neuere Nachrichten für die anfängliche Synchronisierung und verwenden Sie Batch-Anfragen, wo immer möglich, um den Overhead pro Aufruf zu reduzieren.
02
Stille Token-Aktualisierungsfehler

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.

Korrigieren: Behandeln Sie 401-Antworten als Ereignisse für die Trennung des Kontos. Benachrichtigen Sie den Benutzer und fordern Sie eine erneute Authentifizierung an. Speichern Sie ein zuletzt_synchronisiert_um Zeitstempel und Benachrichtigung, wenn diese Ihr erwartetes Synchronisierungsintervall überschreitet.
03
Fehlende E-Mails aufgrund fehlerhafter Ordnerfilter

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.

Korrigieren: Testen Sie Ihre Ordnerabfragen mit echten Konten, einschließlich archivierter, gefilterter und kategorisierter Nachrichten. Für eine umfassende Synchronisierung sollten Sie Folgendes abfragen: ALLES Nachrichten (nicht nur Posteingang) und Filterung nach Datum auf Ihrer Seite.
04
Kodierungsfehler bei internationalen E-Mails

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).

Korrigieren: Immer MIME-Teile gemäß ihrer dekodieren Content-Transfer-Encoding und neu in UTF-8 kodieren. Testen Sie speziell mit E-Mail-Inhalten, die reich an japanischen, arabischen und Emojis sind.
05
Threading-Inkonsistenzen bei verschiedenen Anbietern

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.

Korrigieren: Eine einheitliche API zum Lesen von E-Mails wie Unipile normalisiert die Thread-Darstellung in ein konsistentes Modell über alle Anbieter hinweg und eliminiert die Notwendigkeit, Anbieter-spezifische Logik für die Thread-Rekonstruktion zu implementieren.
FAQ

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.

01
Was ist eine API zum Lesen von E-Mails?
A E-Mail-API lesen ist eine HTTP-Schnittstelle, die es Ihrer Anwendung ermöglicht, sich über OAuth 2.0 oder IMAP-Anmeldeinformationen bei einem bestehenden Postfach eines Benutzers zu authentifizieren und E-Mail-Nachrichten programmgesteuert abzurufen. Sie unterscheidet sich von APIs für transaktionale E-Mails wie SendGrid oder Mailgun, die ausgehende E-Mails von einer von Ihnen kontrollierten Domain versenden. Read-E-Mail-APIs arbeiten mit dem eigenen Gmail-, Outlook- oder IMAP-Konto des Benutzers. Siehe die Umfassender Vergleich von E-Mail-API-Anbietern für einen Überblick über das breitere Ökosystem.
02
Kann ich mit einer API die E-Mails von jemandem lesen?
Sie können E-Mails nur von Konten lesen, für die der Postfachinhaber Ihrer Anwendung über OAuth 2.0 ausdrücklich Zugriff gewährt hat. Der Nutzer muss Ihre Anwendung auf dem Google- oder Microsoft-Zustimmungsbildschirm autorisieren. Sie können nicht ohne die Zustimmung des Kontoinhabers auf E-Mails zugreifen – der Versuch dazu verstößt gegen die Nutzungsbedingungen des Anbieters und in den meisten Gerichtsbarkeiten gegen geltendes Recht.
03
Wie lese ich E-Mails über die Gmail API?
Um E-Mails mit der Gmail API zu lesen: Erstellen Sie ein Google Cloud-Projekt, aktivieren Sie die Gmail API, konfigurieren Sie einen OAuth 2.0-Client, fordern Sie das 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.
04
Was ist der Unterschied zwischen IMAP und der Gmail API?
Die Gmail API ist eine moderne REST API mit OAuth 2.0, Push-Benachrichtigungen über Google Pub/Sub und JSON-Antworten. IMAP ist ein universelles TCP-Protokoll, das von jedem E-Mail-Anbieter unterstützt wird und zustandsbehaftete Verbindungen und Textbefehle verwendet. Die Gmail API ist für reine Gmail-Anwendungsfälle (Echtzeit-Push, Thread-Zugriff, Label-Verwaltung) leistungsfähiger. IMAP bietet universelle Abdeckung über alle Anbieter hinweg, erfordert jedoch Polling- oder IDLE-Verbindungen und verfügt über keine native REST-Schnittstelle. Lesen Sie unsere IMAP API Integrationshandbuch für einen tieferen Vergleich.
05
Gibt es eine kostenlose API zum Lesen von E-Mails?
Ja. Die Gmail API ist innerhalb der Kontingentgrenzen von Google (250 Einheiten/Sekunde/Benutzer, 1 Milliarde Einheiten/Tag) kostenlos. Microsoft Graph für Outlook ist mit Drosselungsgrenzen kostenlos. IMAP ist ein kostenloses offenes Protokoll. Für die Unterstützung mehrerer Anbieter bietet Unipile eine 7-tägige kostenlose Testversion für mit Gmail, Outlook und IMAP verknüpfte Konten. Siehe unsere Kostenloser E-Mail-API-Leitfaden für einen vollständigen Vergleich der kostenlosen Stufen und ihrer realen Grenzen.
06
Wie lese ich E-Mails von mehreren Anbietern mit einer einzigen API?
Nutzen Sie eine einheitliche E-Mail-Lese-API wie Unipile. Unipile stellt einen einzigen Endpunkt (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.
07
Kann ich E-Mail-Anhänge über eine API lesen?
Ja. Die Gmail API gibt Metadaten von Anhängen in der Nachrichten-Payload zurück und bietet einen separaten Endpunkt zum Herunterladen von Anhangsdaten nach ID. Microsoft Graph gibt Anhänge über /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.
08
Wie werde ich benachrichtigt, wenn eine neue E-Mail eintrifft?
Jeder Anbieter hat einen anderen Mechanismus: Gmail verwendet Google Pub/Sub Push-Abonnements (laufen alle 7 Tage ab, erfordern eine Erneuerung). Microsoft Graph verwendet Änderungsbenachrichtigungs-Abonnements (laufen nach ca. 3 Tagen ab). IMAP verwendet den IDLE-Befehl über eine persistente TCP-Verbindung. Alternativ abstrahiert Unipile alle drei in eine einzige email.empfangen Webhook-Ereignis, das für Gmail-, Outlook- und IMAP-Konten ausgelöst wird, mit interner Verwaltung automatischer Abonnements.
09
Wie hoch sind die Ratenbegrenzungen für das Lesen von E-Mails in Gmail und Outlook?
Gmail-API: 250 Quota-Einheiten pro Nutzer pro Sekunde. Das Auflisten von Nachrichten kostet 5 Einheiten, das Abrufen einer vollständigen Nachricht kostet 5 Einheiten. Tägliche Obergrenze sind 1 Milliarde Quota-Einheiten. Microsoft Graph 10.000 Anfragen pro 10 Minuten pro Anwendung pro Mandant. Beide geben bei Drosselung eine HTTP 429 zurück, mit einer Erneut versuchen nach Header. Implementiere exponentielles Backoff mit Jitter für Produktionszuverlässigkeit. IMAP-Limits sind anbieterspezifisch, typischerweise 10-20 gleichzeitige Verbindungen pro Konto.
10
Ist das Lesen von E-Mails von Nutzern über eine API DSGVO-konform?
Das Lesen von E-Mails von Benutzern über eine API kann bei korrekter Implementierung DSGVO-konform sein. Zu den Anforderungen gehören: explizite Zustimmung des Benutzers über OAuth (der Zustimmungsbildschirm erfüllt die Anforderung der Rechtsgrundlage), eine Datenschutzerklärung, die dokumentiert, welche E-Mail-Daten Sie erfassen und aufbewahren, ein Datenlöschungsmechanismus für Löschungsanfragen und eine Datenverarbeitungsvereinbarung mit jeder Drittanbieter-API-Schicht, die Sie verwenden. Unipile ist SOC 2 Typ II zertifiziert und DSGVO-konform, die Dokumentation zur Einhaltung von Vorschriften für Produkte, die auf der Plattform erstellt wurden, zu vereinfachen.

Haben Sie noch Fragen? Sprechen Sie mit einem Entwickler, der die Read-E-Mail-API-Integrationen für Gmail, Outlook und IMAP in großem Maßstab implementiert hat.

Sprechen Sie mit einem Experten
de_DEDE