E-mail API voor ontwikkelaars:
Bouwen met Gmail, Outlook & IMAP
Een praktische naslagwerk voor ontwikkelaars die e-mailintegraties bouwen: vergelijk de Gmail API, Microsoft Graph en IMAP, en zie hoe een uniforme e-mail API voor ontwikkelaars weken aan boilerplate code reduceert tot een enkele REST-oproep.
Wat is een e-mail API voor ontwikkelaars?
Voordat u providers vergelijkt en code schrijft, volgt hier de precieze definitie die zoekmachines en uw teamgenoten beiden nodig hebben.
Een e-mail API voor ontwikkelaars is een programmatische interface waarmee uw applicatie als gebruiker kan authenticeren en vervolgens de e-mails van die gebruiker rechtstreeks in Gmail, Outlook of een andere IMAP-mailbox kan lezen, verzenden of beheren – zonder ooit hun wachtwoord te hoeven verwerken. De API authenticeert via OAuth 2.0 (of IMAP-credentials), retourneert gestructureerde JSON-antwoorden en stuurt webhooks wanneer nieuwe e-mail arriveert. Het is categorisch anders dan een transactionele e-mail-API (SendGrid, Mailgun), die marketing- of notificatiemails verzendt namens uw merk een e-mail-API voor ontwikkelaars die fungeert namens uw gebruiker, in hun bestaande postbus.
In de praktijk: een SaaS helpdesk gebruikt een e-mail API om supporttickets rechtstreeks uit de Gmail inbox van een klant te halen. Een CRM gebruikt deze API om elke e-maildraad te synchroniseren die een verkoper uitwisselt met een prospect. Een AI-agent gebruikt deze API om e-mails te lezen, classificeren en antwoorden op te stellen binnen het Outlook-account van een gebruiker. Dit zijn synchronisatie-side, OAuth user-side integraties – geen massaal verzendende pipelines.
Waarom ontwikkelaars een e-mail API-integratie nodig hebben
Dit zijn de vier productcategorieën waar een e-mail API voor ontwikkelaars directe bedrijfswaarde levert - het lezen en verwerken van echte gebruikers-e-mails, niet het versturen van massa-e-mails.
CRM's, helpdesks en projectmanagementtools hebben live toegang tot de mailbox van een gebruiker. Uw app authenticeert één keer via OAuth, leest vervolgens e-mails, threads en toont deze direct in uw interface - geen copy-paste, geen doorstuurregels. De e-mail API-integratie draait op de achtergrond en houdt uw gegevens up-to-date.
LLM-gestuurde agents moeten lees en classificeer echte e-mails om antwoorden op te stellen, entiteiten te extraheren, workflows te activeren of tickets te routeren. Een e-mail-API voor ontwikkelaars geeft uw AI-agent gestructureerde JSON-toegang tot de inbox - onderwerp, hoofdtekst, bijlagen, headers - zonder een aangepaste e-mailclient te bouwen.
Ondersteuningsmails direct ophalen uit klantmailboxen of gedeelde inboxen, tag ze op onderwerp, wijs ze toe aan agents en plaats antwoorden - allemaal programmatisch. De e-mail-API-integratie vervangt fragiele SMTP-polling door een degelijke REST-interface en realtime webhooks.
Log elke e-mail die een salesmedewerker verzendt of ontvangt tegen het juiste contact of de juiste deal. Houd de open/antwoordstatus bij op threadniveau. Houd uw CRM synchroon met echte gespreksgeschiedenis Zonder verkopers te vragen een magisch adres te BCC'en. Pure API-integratie voor e-mail - aan de gebruikerszijde, OAuth-gebaseerd, namens elke individuele verkoper.
Dit is NIET voor transactionele e-mail. Als uw use case het verzenden van wachtwoordresets, bestelbevestigingen of nieuwsbrieven vanaf uw eigen domein is, dan is dat de transactionele markt (SendGrid, Mailgun, Resend). De e-mail-API van Unipile voor ontwikkelaars richt zich op de markt van synchronisatie/lezen/schrijven namens de gebruiker: andere infrastructuur, andere nalevingsvereisten, ander prijsmodel.
Gmail API, Microsoft Graph, en IMAP vergeleken
Elke e-mail API-integratie begint met een van de drie native providers. Hier is wat elk biedt en waar ze frictie creëren voor ontwikkelaars.
| Functie | Gmail API | Microsoft Graph | IMAP | Unipile (verenigd) |
|---|---|---|---|---|
| Authenticatiemethode | OAuth 2.0 | OAuth 2.0 | Wachtwoord / XOAUTH2 | OAuth 2.0 (alles) |
| Real-time webhooks | Pub/Sub (GCP vereist) | Graafabonnementen | Nee (inactieve polling) | Verenigde webhook |
| Responsvorm | Gmail JSON (niet-standaard) | Grafiek JSON (OData) | RFC 2822 rauwe MIME | Unificado JSON-schema |
| Token verversen | Handleiding (google-auth-library) | Handleiding (MSAL) | N.V.T. | Beheerd door Unipile |
| Tariefgrenzen | 250 QU/user/s | 10k verzoeken/10 min | Varieert per server | Geabstraheerd + opnieuw proberen |
| E-mail verzenden | Ja | Ja | Alleen SMTP | Ja (alle providers) |
| Bijlagen | Vereist extra oproep | Max 4MB inline | Volledige MIME | Unified bijlage-API |
| Installatietijd (schatting) | 1-2 weken | 1-2 weken | 3-5 dagen | Uren |
Native e-mail API versus unified e-mail API: echte codevergelijking
Beide benaderingen naast elkaar zien - in daadwerkelijke code - maakt de afweging concreet. Selecteer hieronder een taal om het lezen van e-mails native versus via de Unipile unified email API te vergelijken.
// 1. OAuth-client installeren en configureren
const {google} = require('googleapis');
const auth = nieuw google.auth.OAuth2(
CLIENT_ID, CLIENT_SECRET, REDIRECT_URI
);
// 2. Wissel autorisatiecode in voor tokens
const {tokens} = wacht op auth.token_ophalen(code);
auth.stuurAanmeldgegevens(tokens);
// 3. Opslaan en automatisch vernieuwen van tokens
// 4. Gmail API aanroepen
const gmail = google.gmail({
versie: 'v1', authenticatie
});
const res = wacht op
gmail.users.messages.list({
userId: "mij, maxResultaten: 10
});
// 5. Haal volledige bericht op per ID
const bericht = wacht op
gmail.users.messages.krijgen({
userId: "mij,
id: res.data.messages[0.id,
formaat 'vol'
});
// 6. Ontleed de base64url-gecodeerde payload zelf2. Eén SDK, alle providers
const eenpaal =
require('@unipile/node-sdk');
const klant =
nieuw eenstemmig.UnipileClient(
API_URL, TOEGANGSTOKEN
);
// 2. Tokens beheerd door Unipile
// Geen handmatige OAuth-stroom nodig
// 3. E-mails weergeven
const e-mails = wacht op
client.e-mail.allesLijsten({
account_id: ACCOUNT_ID,
beperken: 10
});
// 4. Lichaam al gedecodeerd
// Geünificeerde JSON - zelfde schema
// voor Gmail, Outlook, IMAP
console.log(e-mails.items);importeer msal, aanvragen
# 1. Vertrouwelijke klant van MSAL
app = msal.ConfidentialClientApplicatie(
CLIENT_ID,
autoriteit=AUTORITEIT,
client_credential=CLIENT_SECRET
)
# 2. Een token verkrijgen namens de gebruiker
resultaat = app.verkrijg_token_via_autorisatiecode_stroom(
stroom, auth_respons
)
token = resultaat['toegangstoken']
# 3. Zorg voor het vernieuwen van tokens en bewaar deze veilig
# 4. Call Graph API
kopteksten = {'Authorization': f'Bearer {token}'}
r = verzoeken.krijgen(
'https://graph.microsoft.com/v1.0/me/berichten',
kopteksten=kopteksten
)
# 5. Het OData-envelopantwoord parserenimporteer verzoekt
#-token beheerd door Unipile
# Geen MSAL, geen OAuth-configuratie
kopteksten = {
'X-API-KEY': TOEGANGSTOKEN,
'Accepteren': "toepassing/json
}
# werkt voor zowel Gmail als Outlook
# Dezelfde eindpunt, hetzelfde schema
r = verzoeken.krijgen(
'https://api7.unipile.com:13091'
'/api/v1/e-mails',
kopteksten=kop,
parameters={
'account_id': ACCOUNT_ID,
'limiet': 10
}
)
e-mails = r.json()
# Reeds geparseerd, geen OData# IMAP heeft geen REST-API
# Je moet imaplib of node-imap gebruiken
# Geen equivalent voor cURL
# Voorbeeld: openssl s_client
# (alleen voor foutopsporing – niet voor productie)
openssl s_client \
-verbinding imap.gmail.com:993 \
stil
# Stuur vervolgens onbewerkte IMAP-opdrachten:
# A001 INLOGGEN user@gmail.com wachtwoord
# A002 INBOX SELECTEREN
# A003 FETCH 1 RFC822
# A004 UITLOGGEN
# Je ontvangt onbewerkte RFC 2822 MIME
# Moet headers parseren, decoderen
# Base64-onderdelen, ondersteuning voor multipart
#: stel je eigen grenzen
# Ook: geen webhooks, moet via IDLE-polling werken# REST API - werkt met elk
#-e-mailprovider via cURL
krul \
-X GET \
-H ""X-API-KEY: $TOKEN"" \
-H "Accepteer: application/json" \
"https://api7.unipile.com:13091
/api/v1/emails
?account_id=$ACCOUNT_ID
&limit=10"
#-antwoord: schone JSON
# { "items": [ { "id": "...",
# "onderwerp": "Hallo",
# "van": { "naam": "Alice",
# "adres": "..." },
# "body_plain": "...",
# "date": "2026-05-12T..." } ] }
# Hetzelfde eindpunt voor Gmail,
# Outlook en IMAP-accountsEssentiële zaken van OAuth 2.0 voor e-mail API-integratie
Elke product-e-mail-API-integratie is afhankelijk van OAuth 2.0 om te authenticeren als een gebruiker zonder diens wachtwoord op te slaan. Hier is wat u voor elke provider moet instellen - en hoe Unipile dit voor u regelt.
gmail.alleenlezen, gmail.verzenden. Gevoelige scopes vereisen Google-verificatie voor productie.google-authenticatiebibliotheek of een aangepaste handler.Mail.lezen, Mail.verzenden, Mail.ReadWrite.SDK's en tooling voor e-mail API-integratie
Of u nu native bouwt of een uniforme laag gebruikt, de juiste SDK vermindert boilerplate-code. Hier is het huidige landschap voor elke provider en voor Unipile.
Officiële SDK voor de Unipile unified email API. Behandelt e-mail lezen, verzenden, accountbeheer en webhooks voor Gmail, Outlook en IMAP - in één pakket. TypeScript definities inbegrepen.
@azure/msal-node aparte). Goed onderhouden. Het OData responsformaat vereist extra parsing voor simpele gebruiksscenario's.Ontwikkelaarsvriendelijke prijzen: begin gratis, schaal transparant
"Gratis" native e-mail API's zijn niet echt gratis. Gmail API en Microsoft Graph kosten nul dollar per API-aanroep, maar elk vereist weken engineering: OAuth-verificatierondes, logica voor het vernieuwen van tokens, webhook-infrastructuur, herhaallogica, mapping van fouten. Een middelgroot team besteedt doorgaans 3 tot 6 weken voordat een enkele functie wordt geleverd. Unipile's uniforme e-mail API voor ontwikkelaars vervangt dat werk door een gratis proefperiode van 7 dagen, geen creditcard vereist.
Conclusie: De API-aanroepen zijn gratis, de engineering niet. Het bouwen van productieklare e-mailintegratie bovenop native API's (authenticatiestromen, tokenvernieuwing, foutafhandeling, webhook-infrastructuur, multi-provider abstractie) kost doorgaans 3 tot 8 weken aan senior ontwikkelaarstijd per provider, plus doorlopend onderhoud telkens wanneer Google of Microsoft een ingrijpende wijziging doorvoert. Unipile prijzen per gekoppeld account per maand met transparante niveaus. Zie de Gratis e-mail API-handleiding voor de volledige uitsplitsing.
Beveiliging en naleving voor e-mail API-integraties
Wanneer uw applicatie e-mails van gebruikers afhandelt, is naleving niet optioneel. Unipile is gebouwd voor de twee frameworks die ertoe doen voor ontwikkelaargerichte producten die Europese en bedrijfsgegevens verwerken.
Unipile is SOC 2 Type II gecertificeerd. De audit omvat de vertrouwensdienstcriteria Beveiliging, Beschikbaarheid en Vertrouwelijkheid. Dit betekent dat onafhankelijke auditors de controles van Unipile over een langere periode hebben geverifieerd - niet slechts op één enkel moment. Vereist door de meeste zakelijke kopers en SaaS-beveiligingsvragenlijsten.
Unipile verwerkt e-mailgegevens als een gegevensverwerker Volgens AVG Artikel 28 zijn er voor alle betaalde abonnementen gegevensverwerkingsovereenkomsten beschikbaar. Gebruikerse-mailgegevens worden alleen verwerkt gedurende de geauthenticeerde sessie en binnen de reikwijdte die door de OAuth-toestemming van de gebruiker is verleend. Geen parallelle opslag, geen gegevensverkoop aan derden.
Veelvoorkomende valkuilen bij e-mail API-integratie (en hoe ze op te lossen)
Elke ontwikkelaar die zijn eerste e-mail API-integratie bouwt, stuit op dezelfde vier muren. Hier zijn ze - en hoe je ze elk correct aanpakt.
De limiet van 250 quota-eenheden per gebruiker per seconde in Gmail lijkt ruim, totdat je beseft dat het weergeven van 10 berichten elk 5 tot 10 eenheden kost en het ophalen van de volledige tekst per byte aan de quota telt. Microsoft Graph hanteert een limiet van 10.000 verzoeken per 10 minuten per app per tenant. Als de limiet wordt bereikt, wordt de foutmelding 429 - Te veel verzoeken weergegeven. Zonder opnieuw proberen logica crasht je synchronisatieloop stil.
Google-toegangstokens verlopen na 3.600 seconden. Microsoft-tokens na 60-90 minuten. Als uw vernieuwingstoken wordt ingetrokken (wachtwoord wijzigen, toegang tot apps intrekken, of token is 6 maanden niet gebruikt bij Google), stopt de gehele synchronisatie stilletjes. Geen foutmelding wordt weergegeven, tenzij je de reactie van de refresh-aanroep bewaakt.
Microsoft Graph-abonnementen verlopen na maximaal 4.230 minuten (~3 dagen voor e-mail). Vergeten ze te vernieuwen betekent geen pushmeldingen meer - uw app valt terug op peilingen of mist gebeurtenissen volledig. Gmail Pub/Sub-abonnementen zijn persistenter, maar vereisen een GCP-abonnement om geldig te blijven en het onderwerp te bestaan.
E-mail-API's zijn uiteindelijk consistent. Als uw synchronisatieproces halverwege vastloopt, kunt u dubbele e-mails, een pagina met resultaten overslaan of verwijderingen missen. Gmail gebruikt historyId voor incrementele synchronisatie; Microsoft Graph gebruikt deltaToken. Beide vereisen zorgvuldig cursorbeheer na herstarts. IMAP heeft geen native synchronisatiestatus - je moet je eigen UID-tracking onderhouden.
E-mail API voor ontwikkelaars - veelgestelde vragen
Antwoorden op de vragen die ontwikkelaars het meest stellen bij het bouwen van hun eerste e-mail API-integratie voor Gmail, Outlook en IMAP.
npm install @unipile/node-sdk. Maak vervolgens een client aan met uw API-URL en toegangstoken, en bel client.email.listAll() om e-mails te lezen of client.email.verstuur() om te verzenden - via Gmail, Outlook en IMAP met een enkel codeblok. Gebruik voor native Gmail de googleapis npm-pakket. Gebruik voor Microsoft Graph @microsoft/microsoft-graph-client.