Nu bouwen

E-mails lezen via API: Een gids voor ontwikkelaars voor toegang tot de mailbox (2026)

Inhoudsopgave
Secties doorbladeren
Ontwikkelaarsgids 2026

E-mails lezen via API: Een ontwikkelaarsgids voor Inbox Toegang

Reikwijdte Deze gids behandelt sync-API's voor het lezen van bestaande inboxen van gebruikers - Gmail API, Microsoft Graph, IMAP en uniforme lagen zoals Unipile. Dit is anders dan transactionele services (SendGrid, Mailgun) die uitgaande e-mail vanaf uw domein verzenden.

Bouw producten die gebruikersmails programmatisch lezen. Van een enkele GET /api/v1/emails oproepen naar real-time webhooks, deze gids behandelt elke aanpak met werkende code in Node.js, Python en cURL.

Probeer gratis Handleiding voor e-mail-API
lees_inbox.js
// E-mails lezen met één uniforme API-aanroep const response = wacht op fetch( 'https://api3.unipile.com:POORT/api/v1/emails', { headers: { 'X-API-KEY': process.env.UNIPILE_API_KEY, 'account_id': accountId } } ); const { e-mails } = wacht op antwoord.json(); // Dezelfde JSON-structuur voor Gmail, Outlook en IMAP e-mails.voorElk(e-mail => { console.log(onderwerp.email, afzender.email); });
200 OK - 47 e-mails teruggegeven (Gmail + Outlook + IMAP)
Werkt met: Gmail Outlook IMAP Gmail, Outlook & IMAP
Definitie

Wat is een Read Email API?

Een read email API is een HTTP-interface waarmee je applicatie e-mails uit de bestaande mailbox van een gebruiker kan openen, ophalen en verwerken - zonder wachtwoorden op te slaan of provider-specifieke integraties te bouwen. Het is de basis van elk product dat inzicht in de inbox nodig heeft: CRM-synchronisatie, AI-e-mail copiloten, ondersteuningsautomatisering of nalevingsarchivering.

Snelle definitie

A e-mail API lezen stelt eindpunten beschikbaar om te authenticeren tegen het postvak van een gebruiker (via OAuth 2.0 of IMAP-gegevens), inboxberichten weer te geven, volledige e-mailinhoud met bijlagen op te halen en zich te abonneren op realtime bezorgingsgebeurtenissen. Het werkt met het bestaande Gmail-, Outlook- of IMAP-account van de gebruiker - niet een domein dat u beheert. Dit onderscheidt het van transactionele e-mail-API's (SendGrid, Mailgun, Resend), die uitgaande e-mail verzenden namens uw applicatie.

Deze gids behandelt
E-mailen / E-mail Lezen API's

Maak verbinding met de bestaande inboxes van gebruikers. Lees, synchroniseer en reageer in realtime op e-mails. Authenticatie via OAuth 2.0 of IMAP. De gebruiker verleent toegang tot zijn eigen mailbox.

Voorbeelden: Gmail API, Microsoft Graph, IMAP, Unipile
Niet deze gids
Transactionele e-mail API's

Verzend uitgaande e-mails vanaf een domein dat u beheert. Gebruikt voor ontvangstbewijzen, meldingen, wachtwoordherstel. Geen toegang tot de inbox.

Voorbeelden: SendGrid, Mailgun, Resend, Postmark
Gebruikscases

Waarom het programmatisch lezen van e-mails ertoe doet

Het vermogen om e-mails van gebruikers via API's te lezen, opent een categorie producten die simpelweg onmogelijk waren met SMTP alleen. Hier zijn de vier belangrijkste use cases die de adoptie in 2026 stimuleren.

CRM en Sales Engagement Synchronisatie

Sales tools moeten elke e-mailthread tussen een vertegenwoordiger en een potentiële klant kunnen zien - automatisch, zonder handmatige registratie. Een API voor gelezen e-mails haalt gesprekken rechtstreeks uit de inbox van de vertegenwoordiger en synchroniseert deze in realtime met uw CRM.

E-mailuitwisselingen automatisch vastleggen in contactgegevens
Extraheer deal-relevante signalen uit e-mailthreads
Detecteer antwoordintentie en update pipeline-fase

AI-agenten en e-mail copiloten

Grote taalmodellen hebben context nodig. Door uw AI-agent een realtime stroom inbox-e-mails te voeren, kunt u copiloten bouwen die antwoorden opstellen, threads samenvatten, actiepunten extraheren en gesprekken automatisch prioriteren.

Stream nieuwe e-mails naar een LLM-verwerkingspijplijn
Genereer contextbewuste conceptantwoorden
Taken, datums en afspraken ophalen uit threads

Klantenserviceautomatisering

Supportteams ontvangen dagelijks duizenden e-mails. Een API voor gelezen e-mails laat uw platform inkomende verzoeken classificeren, routeren naar de juiste wachtrij en geautomatiseerde antwoorden activeren - allemaal voordat een mens een ticket opent.

Klassificeer support e-mails op onderwerp en urgentie
Routeren naar wachtrijen van agenten op basis van e-mailinhoud
Automatische antwoorden triggeren voor veelvoorkomende aanvraagpatronen

Compliance, Archivering en eDiscovery

Gereguleerde sectoren moeten elke e-mail bewaren en indexeren. Een API voor gelezen e-mails biedt de programmatische toegang die nodig is om postbussen continu te archiveren, beleidsovertredingen te markeren en e-mailrecords op aanvraag te produceren voor juridische beoordeling.

Continue inbox-archivering voor naleving van GDPR / FINRA
Detectie van beleidsovertredingen in mailboxen van werknemers
eDiscovery-export op aanvraag voor juridische bewaring
Diepgaande analyse van de provider

Native API's voor het lezen van e-mails: Gmail, Outlook en IMAP

Elke grote e-mailprovider biedt zijn eigen read API met verschillende eindpunten, authenticatiemodellen en mogelijkheden. Hier is hoe elke er in de praktijk uitziet.

Gmail API

OAuth 2.0

De Gmail API is een REST API die is gebouwd bovenop de infrastructuur van Google. Het gebruikt users.messages.list om door een postvak te pagineren en gebruikers.berichten.ophalen om een volledige bericht op te halen. Het ondersteunt pushmeldingen via Google Pub/Sub, waardoor realtime inboxbewaking mogelijk is zonder te pollen. Rate limit: 250 quotum-eenheden per gebruiker per seconde.

gmail_lezen.sh
# Berichten in de inbox weergeven (Gmail API) krul -X GET \ "https://gmail.googleapis.com/gmail/v1/users/me/messages?labelIds=INBOX&maxResults=20" \ -H "Authenticatie: Bearer ACCESS_TOKEN" # Een enkele e-mail met de volledige tekst ophalen krul -X GET \ "https://gmail.googleapis.com/gmail/v1/users/me/messages/MESSAGE_ID?format=full" \ -H "Authenticatie: Bearer ACCESS_TOKEN"
Opmerking: Gmail retourneert berichten als base64-gecodeerde MIME-delen. Je moet elk deel decoderen en zelf multipart-grenzen parsen om de platte tekst, de HTML en bijlagen te extraheren.

Microsoft Graph (Outlook en Microsoft 365)

OAuth 2.0

Microsoft Graph is de uniforme API voor alle Microsoft 365-services, waaronder persoonlijke Outlook-accounts, Exchange Online en Microsoft 365 zakelijke e-mailaccounts. De /ik/berichten endpoint retourneert berichten met volledige body-inhoud in één verzoek. Pagina-indeling gebruikt $overslaan en $boven OData-parameters. Zie de volledige Microsoft Graph e-mailintegratiehandleiding voor meer informatie.

graph_lezen.sh
# Berichten in de inbox weergeven (Microsoft Graph) krul -X GET \ ""https://graph.microsoft.com/v1.0/me/messages?\$top=20&\$filter=parentFolderId eq 'inbox'"' \ -H "Authenticatie: Bearer ACCESS_TOKEN" \ -H "Content-Type: application/json" # Eén bericht met inhoud ophalen krul -X GET \ ""https://graph.microsoft.com/v1.0/me/messages/MESSAGE_ID?\$select=subject,body,from,receivedDateTime"" \ -H "Authenticatie: Bearer ACCESS_TOKEN"
Opmerking: Microsoft Graph wordt gedoseerd op 10.000 aanvragen per 10 minuten per applicatie per tenant. De hoofdinhoud wordt geretourneerd als HTML of tekst, afhankelijk van de $selecteer en Accepteer headers.

IMAP

Universeel Protocol

IMAP (Internet Message Access Protocol) is het universele e-mailprotocol dat door vrijwel elke mailserver wordt ondersteund. Het is geen REST API, maar een stateful TCP-verbinding via poort 993 (TLS). Je geeft commando's zoals OPHALE, ZOEKen WERKELOOS over de verbinding. Voor een diepere duik, zie onze IMAP API-integratiehandleiding.

imap_read.py
importeer imaplib, e-mail # Verbinding maken en authenticeren e-mail = imaplib.IMAP4_SSL('imap.example.com') e-mail.Login('user@example.com', 'app_wachtwoord') e-mail.select('POSTVAK') # Zoek naar verborgen berichten status, bericht_ids = e-mail.zoek(Niets, 'ONGEZIEN') voor msg_id in bericht_ids[0].deel(): _, gegevens = e-mail.fetch(msg_id, '(RFC822)') bericht = e-mail.bericht_van_bytes(gegevens[0][1]) print(bericht['onderwerp'], bericht['van'])
Opmerking: IMAP vereist het onderhouden van langdurige TCP-verbindingen en het zelf beheren van verbindingspools. Real-time levering maakt gebruik van de WERKELOOS commando, dat een verbinding openhoudt en wacht op servermeldingen. Dit schaalt niet gemakkelijk voorbij enkele honderden gelijktijdige accounts.
En Yahoo en andere providers?

Yahoo Mail, ProtonMail, Zoho en andere providers ondersteunen IMAP allemaal als universele fallback, dus ze vallen onder de bovenstaande IMAP-aanpak. Sommige (zoals Yahoo) bieden ook beperkte eigen API's aan, maar geen enkele komt in de buurt van de mogelijkheden van de Gmail API of Microsoft Graph. Voor de meeste producten die meerdere providers ondersteunen, is IMAP de universele fallback voor elke mailbox die niet wordt gedekt door Gmail of Outlook OAuth. unificerende e-mail-API regelt deze onderhandeling automatisch.

Techniek Realiteit

De verborgen complexiteit van het lezen van e-mails op schaal

Het bouwen van een API-integratie voor het lezen van e-mails tegen één enkele provider voor een demo duurt een middag. Het bouwen van een betrouwbare integratie die op productieschaal werkt voor alle providers is een heel andere uitdaging. Dit is wat er engineering-technisch bij komt kijken.

01

OAuth-stroom per provider

Elke provider heeft zijn eigen OAuth 2.0-implementatie, vereisten voor toestemmingsschermen, scopes en tokenlevenscyclus. Het ondersteunen van Gmail en Outlook betekent het onderhouden van twee afzonderlijke OAuth-apps, twee ontwikkelaarsconsoles, twee strategieën voor het vernieuwen van tokens en twee sets nalevingsvereisten (Google CASA Tier 2, Microsoft Publisher Verification).

Gmail:Google Cloud Console-app, CASA Tier 2 voor gevoelige bereiken, toegangstokens van 1 uur
Outlook:Azure AD app-registratie, Uitgeversverificatie, configureerbare token TTL
IMAP:App-wachtwoorden of OAuth (Gmail IMAP gebruikt dezelfde Google OAuth-stroom)
02

Paginatieverschillen

Elke provider paginereert anders. Gmail gebruikt ondoorzichtige paginatokens. Microsoft Graph gebruikt OData $overslaan en volgendeKoppeling cursors. IMAP gebruikt numerieke UID-bereiken. Het implementeren van een consistente paginatie-abstractie over alle drie vereist niet-triviale adaptercode.

Gmail:pageToken cursor, maximaal 500 resultaten per pagina
Grafiek:@odata.nextLink URL, parameters $top/$skip
IMAP:UID FETCH bereiken, CONDSTORE voor incrementele synchronisatie
03

MIME-parsing

E-mails komen binnen als ruwe MIME-documenten met geneste multipart-grenzen, base64- of quoted-printable-codering, meerdere tekensets en inline bijlagen. Gmail retourneert base64url-gecodeerde delen. IMAP retourneert ruwe RFC 822. Geen van beide geeft u een nette platte tekstbody zonder de volledige MIME-boom te parsen.

Risico:Internationale tekens, emoji's en RTL-tekst introduceren coderingstedgevallen die de hoofdinhoud beschadigen
Bijlagen:Moet de MIME-boom doorlopen om Content-Disposition: attachment delen te vinden
04

Limieten en uitstel

Gmail dwingt 250 quota-eenheden per gebruiker per seconde af (vermelding kost 5 eenheden, ophalen 5 eenheden). Microsoft Graph limiteert op 10.000 verzoeken per 10 minuten per app per tenant. Beide retourneren 429-fouten die een exponentiële vertraging met jitter vereisen. Bij 1.000 gekoppelde accounts wordt het beheer van de tarieflimiet een volledig technisch probleem.

Gmail:250 quotastukken/sec/gebruiker. Dagelijkse limiet: 1 miljard stukken
Grafiek:10.000 verzoeken / 10 min / app / tenant. Retry-After header
IMAP:Provider-specifiek, doorgaans 10-20 gelijktijdige verbindingen per account
05

Real-Time: Webhooks versus Polling versus IDLE

Je meldingen ontvangen wanneer er een nieuwe e-mail arriveert, vereist voor elke provider compleet verschillende mechanismen. Gmail gebruikt Google Pub/Sub pushabonnementen die elke 7 dagen moeten worden vernieuwd. Microsoft Graph gebruikt wijzigingsmeldingabonnementen met een maximale levensduur van 4.230 minuten. IMAP gebruikt het IDLE commando, dat een persistente TCP-verbinding per account openhoudt.

Gmail:Pub/Sub push, 7 dagen geldigheid, vereist vernieuwcyclus
Grafiek:veranderNotificaties abonnement, max ~3 dagen verval
IMAP:IDLE-commando, 1 permanente TCP-verbinding per account
06

Thread inconsistenties tussen providers

Gmail groepeert berichten van nature in threads. Microsoft Graph heeft een conversatieId-veld, maar threads gedragen zich anders dan bij Gmail. IMAP heeft geen native threading; je reconstrueert threads handmatig door References en In-Reply-To headers te matchen. Het bouwen van een uniforme thread-weergave die meerdere providers ondersteunt, vereist aanzienlijke normalisatielogica.

Gmail:Native threadId, berichten.lijst?labelIds=INBOX retourneert threadgroepen
Grafiek:conversationId, maar niet gelijk aan Gmail-conversaties
IMAP:Bericht-ID / Referenties-headers handmatig parsen
Architectuur

Lees E-mail API Architectuur: 3 Benaderingen Vergeleken

Er is geen enkele "correcte" architectuur voor het lezen van e-mails. De juiste aanpak hangt af van hoeveel providers u moet ondersteunen, uw technische capaciteit en uw schaalvereisten. Hier is een eerlijke vergelijking.

Aanpak Voordelen Cons Wanneer te gebruiken
Directe provider API's
Gmail API, Microsoft Graph		 Gratis niveau, volledige toegang tot functies, geen tussenliggende latentie OAuth-instellingen per provider, MIME-parsing, afzonderlijk limietbeheer, geen normalisatie tussen providers Alleen enkele provider
Zelf gehoste IMAP
imaplib, node-imap		 Universeel protocol, werkt met elke mailbox, geen OAuth-app vereist Stateful TCP-verbindingen, geen pushmeldingen (polling of IDLE), connection poolbeheer, traag op schaal Alleen legacy / on-premise
Unified API voor het lezen van e-mail
Eenpaal		 Eén eindpunt voor alle providers, genormaliseerde JSON-respons, beheerde OAuth, uniforme webhooks, ingebouwde retry-logica Extra API-aanroepkosten per gekoppelde account, externe afhankelijkheid Multi-provider producten
Directe provider API's
Gmail API, Microsoft Graph
Voordelen Gratis niveau, volledige toegang tot functies, geen tussenliggende latentie
Cons OAuth-instellingen per provider, MIME-parsing, afzonderlijk limietbeheer, geen normalisatie tussen providers
Wanneer te gebruiken Alleen enkele provider
Zelf gehoste IMAP
imaplib, node-imap
Voordelen Universeel protocol, werkt met elke mailbox, geen OAuth-app vereist
Cons Stateful TCP-verbindingen, geen pushmeldingen (polling of IDLE), connection poolbeheer, traag op schaal
Wanneer te gebruiken Alleen legacy / on-premise
Unified API voor het lezen van e-mail
Eenpaal
Voordelen Eén eindpunt voor alle providers, genormaliseerde JSON-respons, beheerde OAuth, uniforme webhooks, ingebouwde retry-logica
Cons Extra API-aanroepkosten per gekoppelde account, externe afhankelijkheid
Wanneer te gebruiken Multi-provider producten
Beste voor één leverancier
Directe Provider API

Als elke gebruiker in uw product Gmail gebruikt, bouw dan direct tegen de Gmail API. U krijgt volledige functiepariteit, geen extra kosten en toegang tot Gmail-specifieke functies zoals labels, threads en Pub/Sub push.

Beste voor bestaande systemen
Zelf gehoste IMAP

On-premise mailservers, bedrijfsmatige Exchange-implementaties zonder toegang tot de Graph API, of elk scenario waarin OAuth niet beschikbaar is. Gebruik IMAP als een fallback, niet als een primaire strategie voor nieuwe producten.

Beste voor SaaS-producten
Unified e-mail lees API

Wanneer uw gebruikers Gmail, Outlook en IMAP e-mailboxen hebben en u één consistente API voor het lezen van e-mails nodig heeft voor al deze accounts, elimineert een uniforme laag zoals Unipile het N-provider integratieprobleem volledig.

5 minuten installatie

E-mails lezen met de Unified Read Email API van Unipile

Unipile abstraheert de Gmail API, Microsoft Graph en IMAP achter één API voor het lezen van e-mails. Eén OAuth-stroom, één eindpunt, één genormaliseerde JSON-vorm - ongeacht op welke provider het postvak van uw gebruiker zich bevindt. Hier leest u hoe u binnen 5 minuten uw eerste inbox kunt lezen.

1
Authenticeer een gebruiker met de gehoste authenticatielink

Genereer een gehoste authenticatielink vanuit je Unipile dashboard. Stuur deze link naar je gebruiker - zij voltooien de OAuth-goedkeuringsstroom voor hun provider (Gmail-, Outlook- of IMAP-gegevens) op de gehoste pagina van Unipile. Geen OAuth-app-setup, geen configuratie van de redirect URI aan jouw kant. Zie de leidraad voor een uniforme e-mail-API voor de volledige authenticatiestroom.

auth_link.sh
# Genereer een gehoste authenticatielink voor uw gebruiker krul -X POST \ "https://api3.unipile.com:PORT/api/v1/hosted/accounts/link" \ -H "X-API-KEY: JOUW_API_SLEUTEL" \ -H "Content-Type: application/json" \ -d '{"type":"EMAIL","name":"user@example.com","success_redirect_url":"https://yourapp.com/connected"}' #-antwoord: { "url": "https://auth.unipile.com/..." } # Stuur deze URL naar je gebruiker – hij of zij voltooit de OAuth-procedure bij zijn of haar provider
2
Inbox e-mails weergeven - GET /api/v1/emails

Zodra de gebruiker hun account heeft gekoppeld, roep dan het e-mailadres endpoint aan met hun account_id. Het antwoord is identiek, ongeacht of de onderliggende mailbox Gmail, Outlook of IMAP is.

list_emails.sh
# E-mails in de inbox weergeven (werkt voor Gmail, Outlook en IMAP) krul -X GET \ "https://api3.unipile.com:POORT/api/v1/emails?account_id= ACCOUNT_ID&limit=50" \ -H "X-API-KEY: JOUW_API_SLEUTEL" # Filteren op map krul "...?account_id=ACCOUNT_ID&folder=POSTVAK&limit=50" -H "X-API-KEY: JOUW_API_SLEUTEL" # Filter alleen ongelezen krul "...?account_id=NUMMER_ ACCOUNT&unread=true" -H "X-API-KEY: JOUW_API_SLEUTEL"
200 OK - genormaliseerde JSON, zelfde vorm voor alle providers
3
Ontvang een e-mail met inhoud en bijlagen

Haal een volledige e-mail op met ID. Unipile retourneert een gedecodeerd, genormaliseerd object met platte tekst body, HTML body en metadata van bijlagen - er is geen MIME-parsing aan jouw kant vereist.

get_email.sh
# Een enkele e-mail ophalen met de volledige tekst + bijlagen krul -X GET \ "https://api3.unipile.com:POORT/api/v1/emails/E-MAIL_ID" \ -H "X-API-KEY: JOUW_API_SLEUTEL" #-antwoordvelden (altijd genormaliseerd): # { "id", "onderwerp", "datum", "van_deelnemer", "aan_deelnemers", # "body", "body_plain", "bijlagen": [{ "id", "bestandsnaam", "grootte" }] }
4
Ontvang nieuwe e-mails in realtime via webhooks

Registreer een webhook-endpoint in uw Unipile-dashboard. Unipile abstraheert Gmail Pub/Sub, Microsoft Graph-wijzigingsmeldingen en IMAP IDLE tot één email.ontvangen gebeurtenis. Geen abonnementsvernieuwing, geen IDLE connection pool om te beheren.

webhook_handler.js
// Unipile roept uw eindpunt aan wanneer een nieuwe e-mail arriveert // Zelfde gebeurtenis voor Gmail-, Outlook- en IMAP-gebruikers app.post('/webhooks/email', (req, res) => { const { event, account_id, email_id } = req.body; als (gebeurtenis === 'e-mail.ontvangen') { // Haal de volledige e-mailgegevens op verwerkNieuweE-mail(account_id, email_id); } res.status verzenden(200); });
Eén webhook-gebeurtenis vervangt Gmail Pub/Sub + Graph-abonnementen + IMAP IDLE
Wil de volledige integratiereferentie?

De volledige API-handleiding voor e-mail behandelt authenticatie, alle eindpunten, paginering, het downloaden van bijlagen, beveiliging en naleving in detail.

Lees de Email API-gids
Codevoorbeelden

E-mails lezen: codevoorbeelden per taal

Productiegereed codefragmenten voor het lezen van e-mails met de unified read email API van Unipile. Alle voorbeelden lezen uit Gmail-, Outlook- en IMAP-accounts met dezelfde code.

Node.js / TypeScript
Python
Ga
readEmails.ts
importeer fetch van 'node-fetch'; const BASIS = 'https://api3.unipile.com:POORT/api/v1'; const API_SLEUTEL = proces.env.UNIPILE_API_SLEUTEL!; interface E-mail { id: snaar; onderwerp: snaar; datum: snaar; van_deelnemer: { display_name: snaar; identificatie: snaar }; body: snaar; lichaam_tekst snaar; bijlagen: { id: snaar; bestandsnaam: snaar; grootte: getal }[]; } // Inbox e-mails weergeven - werkt voor Gmail, Outlook en IMAP async function e-mails lijst(accountID: snaar, limiet = 50) { const res = wacht op fetch( `${BASE}/emails?account_id=${accountId}&limit;=${limit}&folder;=INBOX`, { headers: { 'X-API-KEY': API_SLEUTEL } } ); const gegevens = wacht op res.json(); return data.voorwerpen als E-mail[]; } // Vraag een enkele e-mail op met volledige inhoud + bijlagen async function e-mailadres ophalen(e-mailadres: snaar) { const res = wacht op fetch(`${BASE}/emails/${emailId}`, { headers: { 'X-API-KEY': API_SLEUTEL } } ); return wacht op res.json() als E-mail; } // Gebruik const e-mails = wacht op e-mails lijst('acc_01abc...'); e-mails.voorElk(e => console.log(e.onderwerp, e.van_deelnemer.identifier));
Volledige e-mail API-gids voor JavaScript
e-mails_lezen.py
importeer os importeer verzoekt BASIS = "https://api3.unipile.com:PORT/api/v1" KOPTEKSTEN = {"X-API-SLEUTEL"os.environ["UNIPILE_API_SLEUTEL"]} def e-mails weergeven(account_id: str, limiet: int = 50) -> lijst: """Inbox-e-mails weergeven - werkt voor Gmail, Outlook en IMAP.""" adem = verzoeken.krijgen( f"{BASE}/emails", headers=HEADERS, params={ "account_id"account_id, "limiet"limiet, "folder": "INBOX", }, ) resp.raise_for_status() return resp.json()["items"] def e-mail_ophalen(email_id: str) -> dict: "Haal een enkele e-mail op met body en bijlagen." adem = verzoeken.krijgen(f"{BASE}/emails/{email_id}", headers=HEADERS) resp.raise_for_status() return resp.json() # Gebruik e-mails = e-mails weergeven("acc_01abc...") voor e-mail in e-mails print(e-mail["onderwerp", e-mail["van_deelnemer"]["identificatiemiddel"]) # Volledige tekst ophalen voor eerste e-mail vol = e-mail_ophalen(e-mails[0]["id"]) print(volledig"lichaam_plat"])
Volledige e-mail API handleiding voor Python
read_emails.go
pakket hoofd importeer ( "encoding/json" "fmt" "net/http" "bot" ) type E-mail struct { ID snaar `json:"id"` Onderwerp snaar `json:"onderwerp"` Lege pagina snaar `json:"tekst_platte"` } type ListResponse struct { Items []E-mail `json:"items"` } functie e-mails lijst(accountID string) ([]E-mail, fout) { url := "https://api3.unipile.com:PORT/api/v1/emails?account_id=" + accountID vereist, _ := http.Nieuwe aanvraag("HAAL", url, nul) req.Header.Set("X-API-SLEUTEL", os.Getenv("UNIPILE_API_SLEUTEL")) resp, err := http.DefaultClient.Doe(verzoek) als fout != nul { return nul, uhm } uitstellen resp.Body.Sluiten() en resultaat ListResponse json.NewDecoder(resp.Body).Ontcijfer(&resultaat) return result.Items, nul } functie hoofd() { e-mails, _ := e-mails lijst("acc_01abc...") voor _, e := bereik e-mails { fmt.Println(e.Onderwerp) } }
Real-time

Real-Time E-mail Lezen: Webhooks versus Polling

Weten wanneer een nieuwe e-mail arriveert is net zo belangrijk als deze kunnen lezen. Er zijn drie mechanismen beschikbaar, elk met zeer verschillende operationele kenmerken op schaal.

Vermijd op schaal

Polling

Uw applicatie roept de list emails-endpoint aan op een timer (elke 30 seconden, elke 5 minuten). Eenvoudig te implementeren, maar verbruikt quota, introduceert latentie en schaalt niet voorbij een handvol accounts.

Eenvoudig - geen server-side installatie
API-limieten proportioneel aan accounts x frequentie
5-minuten peiling = 5 minuten vertraging van de melding
Schaalt niet verder dan ongeveer 100 actieve accounts
Provider-specifiek

Native Provider Webhooks

Gmail Pub/Sub en Microsoft Graph-wijzigingsmeldingen pushen gebeurtenissen onmiddellijk naar uw server. Snel en quota-efficiënt, maar elk vereist een aparte instelling, aparte vernieuwingslogica en verschillende gebeurtenisschema's.

Bijna onmiddellijke levering (seconden)
Quota-efficiënt - wordt alleen geactiveerd bij nieuwe e-mails
Gmail: Pub/Sub-abonnement verloopt elke 7 dagen
Grafiek: abonnement max ~3 dagen, moet verlengd worden
IMAP IDLE: 1 TCP-verbinding per account
Aanbevolen

Unipile Unificated Webhooks

Unipile abstraheert alle provider pushmechanismen achter een enkele email.ontvangen een gebeurtenis. Eén eindpunt ontvangt notificaties voor Gmail-, Outlook- en IMAP-accounts; met automatisch abonnementvernieuwing intern afgehandeld.

Eén webhook-URL voor alle providers
Automatische Pub/Sub en Graph vernieuwing
IMAP IDLE intern beheerd per account
Genormaliseerde payload - altijd dezelfde velden
Hoe Unipile e-mailbezorging in realtime abstraheert

Onder de motorkap beheert Unipile Gmail Pub/Sub abonnementen, Microsoft Graph change notification abonnementen en IMAP IDLE verbindingen - per gekoppeld account, automatisch vernieuwd. Uw applicatie registreert één webhook-URL en ontvangt één genormaliseerd event, ongeacht de onderliggende provider.

Gmail Pub/Sub
+
Grafiek Abonnementen
+
IMAP IDLE
->
e-mail.ontvangen gebeurtenis
Beveiliging en naleving

Beveiliging en naleving bij het lezen van e-mails van gebruikers

Toegang tot e-mails van gebruikers brengt aanzienlijke beveiligings- en wettelijke verantwoordelijkheden met zich mee. Hier zijn de vier gebieden die u moet aanpakken voordat u een integratie voor het lezen van e-mails naar productie brengt.

OAuth-bereikminimalisatie

Vraag altijd de minimaal vereiste OAuth-bereik. Voor het lezen van e-mails, gebruik alleen-lezen bereiken - vraag nooit om verzend- of opstelrechten als je applicatie alleen toegang nodig heeft tot de inbox. Gmail alleen-lezen scope is gmail.alleenlezen. Microsoft Graph tegenhanger is Mail.lezen. Het aanvragen van brede scopes activeert strengere beoordelingsprocessen van Google en Microsoft en vermindert het vertrouwen van gebruikers op het toestemmingsscherm.

Beste praktijken voor tokenopslag

OAuth-toegangstokens en vernieuwingstokens zijn inloggegevens. Sla ze op versleuteld tijdens opslag gebruik AES-256 of equivalent, nooit in platte tekst in uw database. Roteer encryptiesleutels volgens een schema. Log nooit tokens in applicatielogs. Implementeer token intrekking wanneer een gebruiker zijn account ontkoppelt - bel het intrekkingseindpunt van de provider, verwijder niet simpelweg het database record.

AVG en datalocatie

E-mailberichten bevatten vaak persoonsgegevens die onder de AVG vallen. U moet in uw privacybeleid precies documenteren welke e-mailgegevens u verzamelt, bewaart, verwerkt en voor hoe lang. Implementeer een datadwervingsproces dat de inhoud van e-mails verwijdert wanneer een gebruiker om verwijdering vraagt. Als u e-mailinhoud opslaat in uw eigen infrastructuur, houd dan rekening met de eisen inzake gegevensresidentie voor EU-klanten.

Google CASA en Microsoft Publisher Verificatie

Toepassingen die om gevoelige Gmail-scopes vragen (inclusief gmail.alleenlezenmoet Google's voltooien CASA Tier 2 beveiligingsbeoordeling voordat ze verder mogen dan de testlimiet van 100 gebruikers. Microsoft vereist Publisher Verificatie voor apps die bepaalde Graph-scopes aanvragen. Beide processen duren weken - plan dienovereenkomstig vóór uw lanceringsdatum. Het gebruik van Unipile neemt deze certificeringen over van het platformniveau.

Unipile compliance certificeringen

Unipile verzorgt de Gmail CASA Tier 2-certificering, Microsoft Publisher Verification, SOC 2 Type II-audit en GDPR-verwerkings-overeenkomsten op platformniveau. Producten die op Unipile zijn gebouwd, erven deze certificeringen in plaats van deze zelfstandig te voltooien.

SOC 2 type II
Google CASA Niveau 2
GDPR-compliant
OAuth 2.0 Alleen-lezen Bereiken
Prijzen

E-mail API Prijzen: Gratis Tiers en Kostenmodellen

De gratis niveaus voor native provider-API's zijn genereus bij laag gebruik, maar de verborgen kosten komen naar voren wanneer u meerdere providers moet ondersteunen, tokenvernieuwing op schaal moet beheren of limieten voor de tarieven moet bereiken. Hier is een eerlijke analyse.

Provider Gratis niveau Kostenmodel Rate limit Verborgen kosten
Gmail API Gratis met quota Quota-eenheden per verzoek. Geen facturering per account 250 eenheden/sec/gebruiker, 1 miljard eenheden/dag CASA Tier 2 beoordeling, MIME-parsing, Pub/Sub vernieuwingslogica
Microsoft Graph Gratis met snelheidsbeperking Inbegrepen bij Microsoft 365 tenant. Geen kosten per gesprek 10.000 verzoeken/10 min/app/huurder Uitgeversverificatieproces, abonnementsverlenging, per huurder OAuth-apps
IMAP (zelf gehost) Vrij protocol Geen API-kosten. Infrastructuurkosten voor verbindingspools Provider-specifiek, ~10-20 verbindingen/account Serverinfrastructuur, beheer van inactieve verbindingen, geen push-ondersteuning
Eenpaal 7 dagen gratis proberen Per gekoppelde account per maand. Zie gratis e-mail API-niveau Intern afgehandeld, ingebouwde herhaallogica API-aanroepkosten per account - verrekend door geëlimineerde OAuth/MIME-engineering
Gmail API
Gratis met quota
Kostenmodel Quota-eenheden per verzoek. Geen facturering per account
Rate limit 250 eenheden/sec/gebruiker, 1 miljard eenheden/dag
Verborgen kosten CASA Tier 2 beoordeling, MIME-parsing, Pub/Sub vernieuwingslogica
Microsoft Graph
Gratis met snelheidsbeperking
Kostenmodel Inbegrepen bij Microsoft 365 tenant. Geen kosten per gesprek
Rate limit 10.000 verzoeken/10 min/app/huurder
Verborgen kosten Uitgeversverificatieproces, abonnementsverlenging, per huurder OAuth-apps
IMAP (zelf gehost)
Vrij protocol
Kostenmodel Geen API-kosten. Infrastructuurkosten voor verbindingspools
Rate limit Provider-specifiek, ~10-20 verbindingen/account
Verborgen kosten Serverinfrastructuur, beheer van inactieve verbindingen, geen push-ondersteuning
Eenpaal
7 dagen gratis proberen
Kostenmodel Per gekoppelde account per maand. Zie gratis e-mail API-niveau
Rate limit Intern afgehandeld, ingebouwde herhaallogica
Verborgen kosten API-aanroepkosten per account - verrekend door geëlimineerde OAuth/MIME-engineering

Beginnend met een gratis e-mail API? De Gmail API en Microsoft Graph bieden beide gratis toegang binnen quota limieten. Unipile biedt een proefperiode van 7 dagen zonder creditcard, die Gmail, Outlook en gekoppelde IMAP-accounts omvat.

Probeer gratis
Veelvoorkomende valkuilen

Veelvoorkomende valkuilen bij het bouwen van een lees-e-mailintegratie

Dit zijn de fouten die consequent leiden tot productie-incidenten voor teams die hun eerste lees-e-mail-API-integratie implementeren. Leer ze voordat u ze tegenkomt.

01
Quota-uitputting op Gmail op schaal

Gmail's 250 quota-eenheden per seconde per gebruiker klinkt gul totdat je 500 accounts hebt en een initiële inbox synchronisatie moet uitvoeren. Het weergeven van 500 berichten kost 2.500 eenheden; het ophalen van elk volledig bericht kost nog eens 2.500. Initiële synchronisaties voor grote postbussen kunnen dagelijkse quota's in uren uitputten.

Repareren: Implementeer exponentiële backoff bij 429-antwoorden, geef prioriteit aan recente berichten voor initiële synchronisatie en gebruik batchverzoeken waar beschikbaar om de overhead per aanroep te verminderen.
02
Stille fouten bij het vernieuwen van tokens

OAuth-vernieuwingstokens verlopen geruisloos - Google trekt ze in na 6 maanden inactiviteit, na een wachtwoordwijziging, of wanneer een gebruiker de toegang intrekt via de instellingen van hun Google-account. Als je vernieuwingslogica voor tokens geen 401-fout detecteert en deze aan de gebruiker toont, stopt je applicatie simpelweg met het lezen van e-mails zonder zichtbare fout.

Repareren: Behandel 401-antwoorden als accountverbrekingsgebeurtenissen. Meld dit aan de gebruiker en vraag om opnieuw te authenticeren. Sla een laatst_gesynchroniseerd_om tijdstempel en waarschuwing wanneer het uw verwachte synchronisatie-interval overschrijdt.
03
Ontbrekende e-mails door onjuiste mapfilters

Gmail-labels en IMAP-mappen zijn geen gelijkwaardige concepten. Gmail's INBOX Het label omvat geen berichten die zijn gearchiveerd (uit de INBOX verwijderd maar niet definitief gewist). De INBOX-map in Microsoft Graph houdt geen rekening met de geselecteerde INBOX ten opzichte van andere vensterindelingen, tenzij u beide opvraagt. Teams merken vaak dat ze 20-40% aan berichten missen vanwege verkeerde aannames over mappen.

Repareren: Test uw mapzoekopdrachten met echte accounts, inclusief gearchiveerde, gefilterde en gecategoriseerde berichten. Voor een volledige synchronisatie kunt u overwegen om ALLES berichten (niet alleen de INBOX) en het filteren op datum aan jouw kant.
04
Coderingfouten in internationale e-mails

E-mailteksten kunnen in allerlei verschillende tekencoderingen voorkomen: UTF-8, ISO-8859-1, Windows-1252, Shift-JIS. Gmail retourneert onderdelen die in base64url zijn gecodeerd. IMAP retourneert onderdelen die in quoted-printable zijn gecodeerd. Als je de ene codering naar de andere decodeert, ontstaat er een beschadigde tekst die onzichtbaar is in je lokale testomgeving (die waarschijnlijk alleen ASCII-e-mails verstuurt).

Repareren: Decodeer MIME-onderdelen altijd volgens hun Content-Transfer-Encoding en codeer het opnieuw naar UTF-8. Test dit specifiek met e-mailberichten die veel Japans, Arabisch en emoji’s bevatten.
05
Inconsistenties in de threading tussen verschillende aanbieders

Om een uniforme weergave van discussiethreads te realiseren voor Gmail-, Outlook- en IMAP-accounts, moeten drie totaal verschillende modellen voor discussiethreads op elkaar worden afgestemd. Gmail heeft eigen thread-ID’s. Outlook heeft conversatie-ID’s die zich anders gedragen. IMAP kent helemaal geen eigen discussiethreads – je reconstrueert threads op basis van Bericht-ID, Referentiesen In-Reply-To kopteksten, die niet altijd aanwezig of correct zijn.

Repareren: Een uniforme API voor het lezen van e-mail, zoals Unipile, zorgt ervoor dat e-mailconversaties voor alle providers volgens een consistent model worden gestructureerd, waardoor het niet meer nodig is om providerspecifieke logica voor het reconstrueren van conversaties te implementeren.
FAQ

E-mail-API - Veelgestelde vragen

De meest gestelde vragen van ontwikkelaars die hun eerste read e-mail API-integratie bouwen.

01
Wat is een API om e-mails te lezen?
A e-mail API lezen is een HTTP-interface waarmee je applicatie zich kan authenticeren bij de bestaande mailbox van een gebruiker (via OAuth 2.0 of IMAP-inloggegevens) en e-mailberichten programmatisch kan ophalen. Dit verschilt van API’s voor transactionele e-mail, zoals SendGrid of Mailgun, die uitgaande e-mail versturen vanaf een domein dat je beheert. API’s voor het lezen van e-mail werken op de eigen Gmail-, Outlook- of IMAP-account van de gebruiker. Zie de volledige vergelijking van e-mail API-providers voor context over het bredere ecosysteem.
02
Kan ik de e-mail van iemand lezen met een API?
Je kunt e-mails alleen lezen van accounts waarvan de postvakhouder via OAuth 2.0-toestemming expliciet toegang tot je applicatie heeft verleend. De gebruiker moet je applicatie autoriseren op het toestemmingsscherm van Google of Microsoft. Je kunt geen e-mails openen zonder toestemming van de accounthouder - dit is in strijd met de servicevoorwaarden van de provider en de toepasselijke wetgeving in de meeste rechtsgebieden.
03
Hoe lees ik e-mails met de Gmail API?
Om e-mails te lezen met de Gmail-API: maak een Google Cloud-project aan, schakel de Gmail-API in, configureer een OAuth 2.0-client, vraag de gmail.alleenlezen bereik, verkrijg een toegangstoken via OAuth-toestemming en roep vervolgens GET /gmail/v1/users/me/messages om berichten te vermelden en GET /users/me/messages/{id}?format=full om individuele e-mails op te halen. Berichten worden geretourneerd als base64url-gecodeerde MIME-delen die u moet decoderen.
04
Wat is het verschil tussen IMAP en de Gmail API?
De Gmail API is een moderne REST API met OAuth 2.0, pushmeldingen via Google Pub/Sub en JSON-responsen. IMAP is een universeel TCP-protocol dat door elke e-mailprovider wordt ondersteund en gebruikmaakt van stateful verbindingen en tekstcommando’s. De Gmail API biedt meer mogelijkheden voor toepassingen die specifiek op Gmail zijn gericht (realtime push, toegang tot conversaties, labelbeheer). IMAP biedt universele ondersteuning voor alle providers, maar vereist polling- of IDLE-verbindingen en beschikt niet over een native REST-interface. Lees onze IMAP API-integratiehandleiding voor een diepere vergelijking.
05
Is er een gratis API om e-mails te lezen?
Ja. De Gmail API is gratis binnen de door Google vastgestelde limieten (250 eenheden/seconde/gebruiker, 1 miljard eenheden/dag). Microsoft Graph voor Outlook is gratis, maar er gelden beperkingen. IMAP is een gratis, open protocol. Voor ondersteuning van meerdere providers biedt Unipile een gratis proefperiode van 7 dagen voor gekoppelde Gmail-, Outlook- en IMAP-accounts. Zie onze gratis e-mail API-handleiding voor een volledig overzicht van de gratis abonnementen en hun daadwerkelijke limieten.
06
Hoe lees ik e-mails van meerdere providers met één API?
Gebruik een uniforme API voor het lezen van e-mail, zoals Unipile. Unipile biedt één enkel eindpunt (GET /api/v1/emails) die genormaliseerde JSON retourneert voor zowel Gmail-, Outlook- als IMAP-accounts. Je verifieert gebruikers eenmalig via een gehoste OAuth-link, waarna Unipile de providerspecifieke OAuth-processen, MIME-parsing en realtime webhook-abstractie afhandelt achter één consistente interface. Bekijk onze Handleiding voor e-mail-API voor de volledige bronvermelding.
07
Kan ik e-mailbijlagen lezen via een API?
Ja. De Gmail API retourneert metagegevens van bijlagen in de berichtinhoud en biedt een apart eindpunt om bijlagegegevens op basis van ID te downloaden. Microsoft Graph retourneert bijlagen via /berichten/{id}/bijlagen. IMAP vereist het parsen van de MIME-structuur om bijlageonderdelen te identificeren. Met Unipile zijn bijlage-metadata (bestandsnaam, grootte, MIME-type) opgenomen in het e-mailantwoord en is bijlage-inhoud beschikbaar via een speciaal eindpunt - er is geen MIME-parsing vereist.
08
Hoe word ik op de hoogte gebracht als er een nieuwe e-mail arriveert?
Elke provider heeft een ander mechanisme: Gmail gebruikt Google Pub/Sub push-abonnementen (verlopen elke 7 dagen, vereisen vernieuwing). Microsoft Graph gebruikt wijzigingsmelding-abonnementen (verlopen na ongeveer 3 dagen). IMAP gebruikt het IDLE-commando via een persistente TCP-verbinding. Als alternatief abstraheert Unipile deze drie tot één email.ontvangen webhook-gebeurtenis die wordt geactiveerd voor Gmail-, Outlook- en IMAP-accounts met automatisch intern beheerd abonnement.
09
Wat zijn de limieten voor het lezen van e-mails op Gmail en Outlook?
Gmail API: 250 quotastatementen per gebruiker per seconde. Berichten weergeven kost 5 eenheden, het ophalen van een volledig bericht kost 5 eenheden. Dagelijkse limiet is 1 miljard quotastatementen. Microsoft Graph: 10.000 verzoeken per 10 minuten per applicatie per tenant. Beide retourneren HTTP 429 wanneer ze worden begrensd, met een Opnieuw-Proberen-Na Kop. Implementeer exponentiële backoff met jitter voor productiebetrouwbaarheid. IMAP-limieten zijn provider-specifiek, doorgaans 10-20 gelijktijdige verbindingen per account.
10
Is het lezen van gebruikers-e-mails via API AVG-conform?
E-mails van gebruikers lezen via een API kan GDPR-conform zijn mits correct geïmplementeerd. Vereisten zijn onder meer: expliciete toestemming van de gebruiker via OAuth (het toestemmingsscherm voldoet aan de wettelijke grondslag), een privacybeleid waarin wordt gedocumenteerd welke e-mailgegevens u verzamelt en bewaart, een mechanisme voor gegevensverwijdering voor verzoeken tot verwijdering, en een verwerkersovereenkomst met elke derde partij API-laag die u gebruikt. Unipile is SOC 2 Type II gecertificeerd en voldoet aan de GDPR., het vereenvoudigen van de compliance-documentatie voor producten die op het platform zijn gebouwd.

Heb je nog vragen? Praat met een ontwikkelaar die lees-e-mail API-integraties heeft geïmplementeerd voor Gmail, Outlook en IMAP op grote schaal.

Praat met een expert
nl_NLNL
en_USEN fr_FRFR es_ESES de_DEDE it_ITIT pt_BRBR pl_PLPL tr_TRTR nl_NLNL