E-mailsynchronisatie-API voor naadloze software-integratie

Unipile - E-mail Synchronisatie API Held
E-mail synchronisatie API - Gids 2026

E-mail Synchronisatie-API: Hoe e-mailsynchronisatie werkt voor SaaS-producten

Bouw SaaS-functies die gebruikersinboxen in realtime synchroniseren. Verbind Gmail, Outlook en IMAP via één e-mailsynchronisatie-API, met webhooks, OAuth-stromen en volledige maptoegang inbegrepen.

sync-emails.js
const UnipileClient = require('@unipile/node-sdk'); const klant = nieuw UnipileClient({ dsn: process.env.UNIPILE_DSN, token: process.env.UNIPILE_TOKEN }); // Gesynchroniseerde e-mails ophalen van gekoppelde account const e-mails = wacht op client.e-mail.e-mails lijst({ account_id: 'acc_gmail_xyz', map: 'POSTVAK', beperken: 50 }); Real-time: webhook registreren wacht op client.webhook.create({ url: 'https://jouwapp.com/webhooks/email', evenementen: ['e-mail.nieuw', 'e-mail.lezen'] });
Uniforme synchronisatie voor Gmail, Outlook en IMAP
Ondersteunt Gmail Outlook IMAP
Definitie

Wat is een E-mail Sync API?

Een e-mail synchronisatie API is een programmatische interface waarmee uw toepassing continu de mailbox van een gebruiker kan spiegelen – nieuwe berichten lezen, statuswijzigingen bijhouden (gelezen/ongelezen, verplaatst, verwijderd) en de mapstructuur weergeven – zonder dat de gebruiker handmatig gegevens exporteert. In tegenstelling tot een API die alleen verzenden toestaat, een e-mailsynchronisatie API onderhoudt een live, tweerichtingsreplica van de inbox binnen uw product.

Op protocolniveau biedt elke provider zijn eigen synchronisatieprimitief: Gmail gebruikt geschiedenis.lijst with a geschiedenisId cursor, Microsoft Graph gebruikt delta-queries om de /berichten/delta endpoint, en standaard IMAP-servers ondersteunen de WERKELOOS commando voor pushmeldingen. A geünificeerde e-mail synchronisatie-API zoals Unipile deze drie protocollen achter één eindpunt abstraheert, zodat je team de synchronisatielogica één keer schrijft en naar alle providers uitrolt.

Als u een CRM, een sales engagement tool, een AI-e-mailassistent, of een SaaS-oplossing die live inboxgegevens nodig heeft, bouwt, is een API voor e-mailsynchronisatie de basis. Voor het verzenden van transactionele e-mails (wachtwoordherstel, facturen) geldt een andere categorie - zie onze complete e-mail API handleiding of onze toegewijde synchronisatie versus transactionele vergelijking.

Realtime inbox mirroring
Gmail, Outlook & IMAP
OAuth 2.0 + token vernieuwing
Webhooks voor nieuwe e-mails
Map + label synchronisatie
Concepten

Email synchronisatie versus e-mail verzenden: Waarom het onderscheid belangrijk is

Ontwikkelaars verwarren vaak e-mail synchronisatie-API's met transactionele e-mail API's. Ze dienen tegenovergestelde doelen. Het kiezen van de verkeerde categorie zet je architectuur weken terug.

Wat je aan het bouwen bent
E-mail synchronisatie API

Leest en spiegelt de bestaande mailbox van een gebruiker in je applicatie. Vereist dat de gebruiker toegang tot zijn account autoriseert (OAuth of IMAP-gegevens). Je app wordt een secundaire lezer van hun inbox.

  • Leest inkomende en uitgaande berichten
  • Gelezen/ongelezen berichten, labels, mappen
  • Webhookmeldingen voor nieuwe e-mails
  • Volledige thread- en bijlagetoegang
  • Delta synchronisatie - haalt alleen wijzigingen op
  • Gebruikt door: CRM's, salestools, AI-e-mailassistenten, helpdesks, e-mailarchivering, inboxanalyse.

    Andere categorie
    Transactionele E-mail API

    Verstuur systeem-gegenereerde e-mails vanuit uw eigen domein. Geen gebruikersautorisatie nodig. U authenticeert als de afzender (API-sleutel), niet als de gebruiker. Voorbeelden: SendGrid, Mailgun, Resend, Amazon SES.

  • Alleen uitgaand (wachtwoord resets, facturen)
  • Geauthenticeerd via API-sleutel, niet OAuth
  • Gericht op leveringspercentage en SPF/DKIM
  • Geen toegang tot gelezen e-mail
  • Geen OAuth-goedkeuring aan de gebruikerszijde vereist
  • Unipile valt NIET in deze categorie. Unipile is de synchronisatiekant - het lezen en spiegelen van gebruikersinboxen via OAuth.

    Gebruikscases

    Wie heeft een e-mail synchronisatie API nodig?

    Elk SaaS-product dat de inkomende e-mail van een gebruiker moet weergeven, analyseren of erop moet reageren, is afhankelijk van een e-mail synchronisatie-API. Dit zijn de vijf meest voorkomende use cases die we in productie zien.

    CRM E-mail synchronisatie

    Log automatisch elke inkomende en uitgaande e-mail bij het juiste contactdossier. Verkoopmedewerkers hoeven e-mails niet meer te kopiëren en plakken; het CRM wordt de real-time bron van waarheid. Geen handmatige BCC-doorgifte vereist.

    E-mail API-handleiding
    Verkoopbetrokkenheid

    Volg reactiepercentages, detecteer out-of-office-antwoorden en start opvolgsequenties op basis van inbox-gebeurtenissen. Een e-mail synchronisatie-API geeft uw sequenties real-time inzicht in wat er gebeurt in de inbox van de prospect.

    E-mail programmatisch verzenden
    AI E-mailagents

    Voer een live e-mailstroom naar een LLM-agent die antwoorden opstelt, binnenkomende berichten categoriseert, actiepunten extraheert of tickets doorstuurt. De agent heeft een continue synchronisatiestroom nodig, geen eenmalige export. Een realtime synchronisatie-API voor e-mail is verplicht.

    E-mails programmatisch lezen
    Helpdeskintegratie

    Converteer e-mails van klanten automatisch naar supporttickets, inclusief alle threadcontext en bijlagen. Synchroniseer de ticketstatus terug wanneer de agent antwoordt, zodat de inbox van de klant de oplossingsdraad weerspiegelt.

    Vergelijk e-mail API-providers
    E-mail archivering

    Leg elke inkomende en uitgaande e-mail vast voor naleving, juridische ontdekking of analyse. Een e-mailsynchronisatie-API stelt u in staat een doorzoekbaar archief van alle bedrijfscommunicatie op te bouwen zonder de mailserver direct aan te raken.

    Gratis e-mail API-niveau
    Inbox Analyse

    Analyse e-mailvolume, responstijden, gespreks patronen en sentiment in de gekoppelde accounts van een team. Marketing, operations en finance teams gebruiken inbox analyse om de kwaliteit van communicatie te meten en knelpunten te identificeren.

    Volledige gids voor de e-mail API
    Onder de kap

    Hoe e-mailsynchronisatie werkt: OAuth, Delta Sync en Webhooks

    Een e-mail synchronisatie-API is meer dan een read-endpoint. Het is een stateful pipeline die gebruikers authenticeert, de frisheid van tokens onderhoudt, de status van de mailbox bijhoudt en wijzigingen in nagenoeg realtime levert. Hier ziet u wat er op elke laag gebeurt.

    1
    OAuth 2.0 Autorisatiestroom

    De gebruiker klikt op "Koppel uw inbox" in uw app. Ze worden doorgestuurd naar het toestemmingsscherm van Google of Microsoft, waar ze de door uw applicatie gevraagde bereiken goedkeuren. Voor Gmail betekent dat gmail.alleenlezen of gmail-aanpassen; voor Outlook betekent dit Mail.lezen of Mail.ReadWrite. Na toestemming ontvangt uw app een toegangstoken (geldig 1 uur voor Google, 1 uur voor Microsoft) en een vernieuwingstoken (langdurig). IMAP-accounts gebruiken gebruikersnaam + wachtwoord of OAuth, afhankelijk van de configuratie van de provider.

    2
    Initiële Postvak Snapshot

    Bij de eerste synchronisatie voert de e-mailsynchronisatie-API een volledige backfill uit: het haalt de lijst met mappen op (INBOX, Verzonden, Concepten, aangepaste labels) en haalt recente berichten op tot een configureerbare geschiedenisdiepte. Voor Gmail wordt hiervoor gebruikgemaakt van users.messages.list met paginering. Voor Microsoft Graph gebruikt het GET /mij/berichten. Voor IMAP geeft het een SELECT INBOX gevolgd door een OPHALE bereik. De snapshot geeft uw database zijn basistoestand, inclusief bericht-ID's en draadgroeperingen.

    3
    Delta Sync - Haal alleen op wat veranderd is

    Na de eerste snapshot, zou het herhaaldelijk pollen van de volledige mailbox quota verspillen en je app vertragen. Delta-synchronisatie is de oplossing. Gmail biedt een geschiedenisId cursor: je belt gebruikers.geschiedenis.lijst met de laatst bekende geschiedenisId en ontvang alleen de wijzigingen (nieuwe berichten, labelwijzigingen, verwijderingen) sinds dat punt. Microsoft Graph gebruikt GET /mij/berichten/delta with a $deltaToken. IMAP wordt gebruikt UID OPHALEN with a VERANDERDSIEN modifier (CONDSTORE-extensie). Dit delta synchronisatie het patroon houdt API-aanroepen minimaal, zelfs voor mailboxes met veel volume.

    4
    Tokenvernieuwing en sessieonderhoud

    Toegangstokens verlopen. Uw e-mail synchronisatie-infrastructuur moet detecteren 401 Niet toegestaan reacties, gebruik de refresh token om een nieuwe access token van Google of Microsoft te verkrijgen en herhaal het mislukte verzoek. Dit moet transparant gebeuren, zonder de sessie van de gebruiker te onderbreken. Refresh tokens kunnen zelf worden ingetrokken - door de gebruiker, door een beheerderbeleid, of na 6 maanden inactiviteit (Google) - dus uw systeem moet intrekking detecteren en de gebruiker vragen om opnieuw te autoriseren.

    5
    Webhooks voor Real-Time Meldingen

    Polls op een schema introduceren latentie - een poll van 30 seconden betekent dat e-mails tot 30 seconden verouderd kunnen zijn. Voor realtime inboxfuncties moet de e-mail-sync API ondersteuning bieden voor pushmeldingen. Gmail maakt gebruik van Google Cloud Pub/Sub: je registreert een onderwerp en Gmail publiceert een melding wanneer er geschiedenisId voorschotten. Microsoft Graph gebruikt wijzigingsmeldingen op de /me/mailFolders/inbox/messages een uniforme e-mailsynchronisatie-API (zoals Unipile) normaliseert deze tot één webhook-gebeurtenis - email.nieuw - geleverd aan uw eindpunt, ongeacht de provider.

    Unipile - Native E-mail Synchronisatie API's
    Diepgaande Analyse van Provider

    Native E-mail Synchronisatie API's: Gmail, Microsoft Graph en IMAP

    Elk van de drie e-mailproviders biedt een ander synchronisatie-element. Het begrijpen van de verschillen laat zien waarom het bouwen van een API voor synchronisatie met meerdere providers vanaf nul maanden in beslag neemt, niet dagen.

    Gmail-logo Gmail - geschiedenis.lijst + Pub/Sub Google Workspace & persoonlijke accounts

    Gmail's synchronisatiemodel is gebouwd rond het geschiedenisId cursor. Na je eerste synchronisatie, elke volgende aanroep van gebruikers.geschiedenis.lijst geeft alleen wijzigingen terug sinds je laatst bekende geschiedenisId - nieuwe berichten, labeltoevoegingen, labelverwijderingen en verwijderingen.

    Voor realtime meldingen, Gmail vereist dat u een Google Cloud Pub/Sub-onderwerp instelt en dat u aanroept Gebruikers.watch om het te registreren. Gmail publiceert vervolgens een melding (met een nieuwe geschiedenisId) aan uw onderwerp wanneer de mailbox wordt gewijzigd. Uw worker abonneert zich op het onderwerp en roept geschiedenis.lijst om de daadwerkelijke wijzigingen op te halen.

    Tariefgrenzen: 1 miljard quotage-eenheden per dag per project, met limieten per gebruiker. gebruikers.berichten.ophalen kost 5 eenheden; gebruikers.geschiedenis.lijst kost 2 eenheden. Voor een multi-tenant app wordt quota-beheer een fulltime zorg. Zie de e-mail API gids voor meer.

    gmail-delta-sync.py
    van googleapiclient.discovery importeer bouwen # Delta-synchronisatie met behulp van de historyId-cursor def wijzigingen_ophalen(service, geschiedenis_id): resultaat = service.gebruikers().geschiedenis().list( gebruikersId="mij, startGeschiedenisId=geschiedenis_id, historieTypen=[ 'berichtToegevoegd', 'berichtVerwijderd', 'labelToegevoegd' ] ).uitvoeren() return result.haal('geschiedenis', [])
    Outlook en Microsoft 365 logo Outlook / Microsoft 365 - Graph delta queries Outlook en Exchange Online / M365 Persoonlijk

    Microsoft Graph gebruikt delta queries op de /ik/berichten/delta eindpunt. De eerste aanroep retourneert een volledige pagina met berichten plus een @odata.deltaLink. Latere aanroepen van die deltakoppeling retourneren alleen gewijzigde berichten sinds het vorige aanroep - nieuwe, gewijzigde en verwijderde items.

    Voor realtime meldingen, ondersteunt Microsoft Graph wijzigingsmeldingen via webhooks. U registreert een abonnement op /me/mailFolders/inbox/messages with a meldingUrl. Microsoft stuurt een POST naar uw URL wanneer berichten veranderen. Abonnementen moeten elke 4230 minuten (ongeveer 3 dagen) worden verlengd, anders verlopen ze.

    Opmerking: Dit omvat zowel persoonlijke Outlook-accounts als Microsoft 365/Exchange Online; ze gebruiken dezelfde Graph API. Zie de Microsoft Graph e-mailintegratiehandleiding voor details over app-registratie en beheerdersgoedkeuring.

    graph-delta-sync.js
    // Microsoft Graph delta synchronisatie async function haalDeltaBerichten(klant, deltaLink) { const url = deltaLink || '/ik/berichten/delta'; const res = wacht op klant .API(url) .select('id,onderwerp,van,ontvangenDatumTijd') .krijgen(); return { berichten: res.waarde, nextDelta: res['@odata.deltaLink'] }; }
    IMAP logo IMAP - IDLE commando + UID FETCH Universele back-up voor elke mailserver

    IMAP (RFC 3501) dateert van decennia geleden en ging vooraf aan moderne synchronisatie-API's. Het legt per map bloot Volgnummers en UID's. Voor delta synchronisatie, de CONDSTORE uitbreiding (RFC 7162) voegt een MODSEQ waarde aan elk bericht, waardoor je alleen berichten kunt ophalen met een MODSEQ hoger dan uw laatst bekende waarde via UID FETCH * (FLAGS) (CHANGEDSINCE modseq).

    Voor realtime meldingen, IMAP ondersteunt de WERKELOOS commando (RFC 2177). Uw client stuurt WERKELOOS en de server pusht BESTAAT of UITWISSELEN reacties wanneer de map wijzigt - geen polling nodig. De meeste IMAP-servers ondersteunen IDLE; verbindingen moeten elke 29 minuten worden vernieuwd om time-outs te voorkomen.

    IMAP is essentieel omdat het elke mailserver dekt die niet door Google of Microsoft wordt beheerd: Exchange van bedrijven (on-premise), ProtonMail, Zoho, Fastmail en aangepaste domeinen. Zie de IMAP-integratiehandleiding voor een volledige implementatie doorloop.

    imap-idle-sync.js
    const Imap = require('imap'); const imap = nieuw Imap({ host, poort: 993, tls: true }); imap.eens('klaar', () => { imap.openBox('POSTVAK', true, () => { imap.on('e-mail', (aantalNieuw) => { // IDLE push: nieuwe e-mail gearriveerd haalNieuweBerichten(aantalNieuw); }); }); });
    Unipile - E-mail API Functiedekking
    API Mogelijkheden

    E-mail API Functiedekking per Provider

    Eén Unipile-integratie geeft je toegang tot alle e-mailbewerkingen via providers als Gmail, Outlook en IMAP. Klik op een providerkop om de volledige integratiehandleiding te lezen.

    Functie Gmail Outlook / M365 IMAP / SMTP
    Authenticatie
    OAuth2 (geen wachtwoordopslag) App-wachtwoord
    Gehoste authenticatie / toestemmingsstroom
    Automatische tokenvernieuwing
    E-mail Beheer
    E-mail verzenden vanuit gebruikersaccount
    Lees & lijst e-mails
    Verzenden met bijlagen
    Reageer in bestaande thread
    Conceptbeheer
    Labels / Mappen Labels Mappen Mappen
    Dagelijks verzendlimiet (ongeveer.) ~500 / dag ~10.000 / dag Serverafhankelijk
    Synchroniseren en gebeurtenissen
    Real-time webhooks
    Incrementele delta-synchronisatie
    Draadgroepering
    SOC 2 Type II / CASA Tier 2
    Authenticatie
    OAuth2 (geen wachtwoordopslag)
    GmailGmail
    OutlookOutlook / M365
    IMAPIMAP / SMTP
    App-wachtwoord
    Gehoste authenticatie / toestemmingsstroom
    GmailGmail
    OutlookOutlook / M365
    IMAPIMAP / SMTP
    Automatische tokenvernieuwing
    GmailGmail
    OutlookOutlook / M365
    IMAPIMAP / SMTP
    E-mail Beheer
    E-mail verzenden vanuit gebruikersaccount
    GmailGmail
    OutlookOutlook / M365
    IMAPIMAP / SMTP
    Lees & lijst e-mails
    GmailGmail
    OutlookOutlook / M365
    IMAPIMAP / SMTP
    Verzenden met bijlagen
    GmailGmail
    OutlookOutlook / M365
    IMAPIMAP / SMTP
    Reageer in bestaande thread
    GmailGmail
    OutlookOutlook / M365
    IMAPIMAP / SMTP
    Conceptbeheer
    GmailGmail
    OutlookOutlook / M365
    IMAPIMAP / SMTP
    Labels / Mappen
    GmailGmail
    Labels
    OutlookOutlook / M365
    Mappen
    IMAPIMAP / SMTP
    Mappen
    Dagelijks verzendlimiet (ongeveer.)
    GmailGmail
    ~500 / dag
    OutlookOutlook / M365
    ~10.000 / dag
    IMAPIMAP / SMTP
    Serverafhankelijk
    Synchroniseren en gebeurtenissen
    Real-time webhooks
    GmailGmail
    OutlookOutlook / M365
    IMAPIMAP / SMTP
    Incrementele delta-synchronisatie
    GmailGmail
    OutlookOutlook / M365
    IMAPIMAP / SMTP
    Draadgroepering
    GmailGmail
    OutlookOutlook / M365
    IMAPIMAP / SMTP
    SOC 2 Type II / CASA Tier 2
    GmailGmail
    OutlookOutlook / M365
    IMAPIMAP / SMTP
    Probeer gratis

    Sla de standaard Gmail + Graph + IMAP boilerplate over. Eén e-mail synchronisatie API dekt ze alle drie.

    De unificleerd-e-mail-sync API van Unipile maakt verbinding met Gmail, Outlook en IMAP via één enkel eindpunt. OAuth-flows, tokenvernieuwing, delta-synchronisatie en webhooks - alles wordt voor u geregeld. Begint gratis, geen creditcard vereist.

    Geen creditcard
    Gratis e-mail API-niveau beschikbaar
    In 5 minuten operationeel
    Techniek Realiteit

    De verborgen complexiteit van e-mailsynchronisatie op schaal

    Het bouwen van een proof-of-concept e-mail sync API kost een weekend. Het bouwen van een betrouwbare productieversie met 1.000 gekoppelde accounts kost maanden. Dit is wat niemand je van tevoren vertelt.

    Beheer van tarieflimieten

    Gmail hanteert per gebruiker quota (250 quota-eenheden/seconde) en dagelijkse limieten per project. Microsoft Graph limiteert op 10.000 aanvragen/10 minuten per app. Met 500 gekoppelde accounts die allemaal volgens schema synchroniseren, heb je een gedistribueerde rate-limiter nodig met exponentiële backoff, jitter en per-account wachtrij-isolatie. Een enkele piek van één account kan de quota voor alle andere uitputten.

    Tokenvernieuwing op schaal

    Elke gekoppelde account heeft een toegangstoken die verloopt. Bij 1.000 accounts kunt u tientallen gelijktijdige tokenvernieuwingen verwachten tijdens piek synchronisatievensters. Eén mislukte vernieuwing kan leiden tot gemiste synchronisatiecycli. U heeft een speciale service voor de levenscyclus van tokens nodig, met opnieuw proberen-logica, detectie van intrekking en een waarschuwingspijplijn om gebruikers te vragen opnieuw te autoriseren wanneer vernieuwingstokens verlopen.

    Map en label complexiteit

    Gmail gebruikt labels (een bericht kan meerdere labels tegelijk hebben). Outlook gebruikt mappen (hiërarchisch, met verplaatsingsbewerkingen). IMAP gebruikt ook mappen, maar met namespaces die per serverleverancier variëren. Het normaliseren hiervan naar een consistent mapmodel voor uw app vereist leveranciersspecifieke mappinglogica. Randgevallen omvatten gedeelde postbussen, gedelegeerde toegang en het onderscheid tussen Gmails "Alle e-mail" en "Postvak IN".

    Opslag en streaming van bijlagen

    E-mailbijlagen kunnen groot zijn. Het ophalen en opslaan van bijlagen voor elke gesynchroniseerde e-mail in duizenden accounts loopt snel op in zowel bandbreedte- als opslagkosten. Je hebt een streaming-pipeline nodig die bijlagen alleen op aanvraag downloadt, deduplicerende opslag, en een CDN-laag om ze vanuit je product te serveren. MIME-parsing zelf introduceert bugs - multi-part e-mails, quoted-printable codering en inline bijlagen vereisen elk specifieke afhandeling.

    Draden Herbouw

    Gmail-gesprekken op threadId - een server-side concept. IMAP heeft geen native threading; je reconstrueert threads met behulp van de Referenties en In-Reply-To headers (RFC 5322). Outlook heeft conversatieId. Het normaliseren van threads over providers heen - vooral voor antwoorden tussen providers - vereist fallback heuristieken op basis van onderwerpnormalisatie en message-ID kettingen.

    Webhook Betrouwbaarheid en Herlevering

    Gmail Pub/Sub-meldingen zijn niet gegarandeerd - gemiste berichten tijdens downtime worden niet opnieuw verzonden. Microsoft Graph webhook-abonnementen verlopen en moeten worden vernieuwd. Als uw webhook-ontvanger down is tijdens een pushmelding, mist u het gebeurtenis en valt u terug op polling. Een API voor synchronisatie van productie-e-mails heeft een reconciliatielus nodig die gemiste gebeurtenissen periodiek bijwerkt met behulp van de delta-synchronisatiecursor, onafhankelijk van de beschikbaarheid van webhooks.

    Architectuurvergelijking

    3 E-mail Synchronisatie Architecturen Vergeleken

    Teams die e-mails synchronisatiefuncties bouwen, evalueren doorgaans drie implementatiepatronen. Hier is een eerlijke vergelijking van elk, van de bouwinspanning tot de lopende onderhoudskosten.

    Zelfdoen
    Directe Integratie van Leverancier
    Gmail API + Microsoft Graph + IMAP - apart
    Bouwtijd 3-6 maanden
    Meegeleverde providers 1 per sprint
    OAuth / tokenbeheer 3x codebasis
    Webhook-verwerking 3 verschillende systemen
    Lopend onderhoud Hoog (API-wijzigingen)
    Kostenmodel Ingenieursuren
    Zelf gehost
    Zelf-gehoste IMAP-laag
    Voer uw eigen mailproxy uit (Dovecot / Cyrus / custom)
    Bouwtijd 2-4 maanden
    Meegeleverde providers IMAP alleen (breed)
    OAuth / tokenbeheer Alleen IMAP-gegevens
    Webhook-verwerking IDLE-gebaseerd, aangepast
    Lopend onderhoud Medium
    Kostenmodel Infra + engineering
    Snelstart

    Synchroniseer e-mails met de Unified Email Sync API van Unipile

    De e-mailsynchronisatie-API van Unipile ondersteunt Gmail, Outlook en IMAP via één uniforme interface. OAuth-stromen, tokenvernieuwing, delta-synchronisatie en webhooklevering worden allemaal voor u beheerd – uw team levert de functie, niet de infrastructuur.

    1
    Maak een Unipile-account aan

    Meld je aan bij dashboard.unipile.com. De gratis e-mail API-laag geeft je toegang tot alle providers zonder creditcard. Je DSN (Data Source Name) en API-token krijg je direct.

    2
    Koppel een e-mailaccount van een gebruiker

    Gebruik Unipile's gehoste OAuth-stroom om uw gebruiker toegang te laten verlenen tot hun Gmail- of Outlook-account. Verzamel voor IMAP hun inloggegevens en geef deze door aan POST /accounts. Unipile handelt de OAuth-redirect, tokenuitwisseling af en slaat de refresh token veilig op.

    3
    Gesynchroniseerde e-mails weergeven

    Roepen GET /emails met de account_id van de gekoppelde rekening. Unipile voert de delta-synchronisatie uit tegen Gmail's geschiedenis.lijst, de delta-eindpunt van Microsoft Graph, of IMAP's CONDSTORE - je krijgt altijd dezelfde genormaliseerde JSON-respons, ongeacht de provider.

    4
    Registreer een webhook voor realtime synchronisatie

    POST uw endpoint URL naar Unipile's webhook API. Wanneer er een nieuwe e-mail binnenkomt in een gekoppelde account - of het nu Gmail, Outlook of IMAP is - levert Unipile een genormaliseerd email.nieuw gebeurtenis naar uw URL. Geen Pub/Sub-configuratie, geen verlenging van de Graph-abonnementen, geen beheer van inactieve verbindingen. Zie de e-mail API gids voor volledige referentie van het evenement.

    5
    Volledige e-mailinhoud en bijlagen lezen

    Roepen GET /emails/{id} om de volledige berichttekst (HTML en platte tekst), headers, MIME-onderdelen en bijlageverwijzingen op te halen. Bijlagen worden geserveerd via ondertekende URL's - u hoeft nooit zelf ruwe MIME-gegevens op te slaan. Zie e-mails programmatisch lezen als voorbeelden.

    unipile-email-sync.js
    const axios = require('axios'); const DSN = proces.env.UNIPILE_DSN; const TOKEN = proces.env.UNIPILE_TOKEN; const API = axios.create({ basISUrl: `https://${DSN}/api/v1`, headers: { 'X-API-KEY': TOKEN } }); // Stap 3 - Gesynchroniseerde e-mails weergeven async function e-mails lijst(accountID) { const { gegevens } = wacht op api.krijgen('/e-mails', { params: { account_id: accountId, map: 'POSTVAK', beperken: 20 } }); return gegevens.items; } // Stap 4 - Registreer webhook async function registreerWebhook() { wacht op api.post(/webhooks, { url: 'https://jouwapp.com/api/email-events', evenementen: ['e-mail.nieuw', 'email.bijgewerkt'] }); } // Stap 5 - Haal volledige e-mailinhoud op async function e-mailadres ophalen(e-mailadres) { const { gegevens } = wacht op api.krijgen(`/emails/${emailId}`); return gegevens; }
    Werkt met Gmail, Outlook & IMAP - dezelfde code
    Unipile E-mailsynchronisatie API

    Stop met het opnieuw opbouwen van dezelfde e-mail synchronisatiepijplijn voor elke provider.

    Synchroniseer Gmail, Outlook en IMAP via één e-mailsynchronisatie-API. Realtime webhooks, delta-synchronisatie en OAuth-tokenbeheer – alles geregeld. Uw team focust op het product, niet op de infrastructuur.

    Unipile - Real-Time E-mail Synchronisatie Vergelijking
    Real-time Opties

    Real-time E-mail Sync: Webhooks vs Polling vs IMAP IDLE

    Het kiezen van het verkeerde real-time mechanisme voor uw e-mailsynchronisatie-API voegt latentie toe, verbruikt quota, of laat uw app blind achter tijdens storingen. Hier is een directe vergelijking van de drie benaderingen.

    Aanpak Hoe het werkt Latency Het beste voor Complexiteit
    Webhooks (push) Provider stuurt een HTTP POST naar uw eindpunt wanneer een postvak verandert. Gmail gebruikt Pub/Sub; Microsoft Graph gebruikt wijzigingsmeldingen. Onder 5 jaar Gmail, Outlook, uniforme API's zoals Unipile Medium abonnementbeheer vereist
    Polling (gepland) Uw worker roept de provider API aan op een schema (elke 30 seconden, 1 minuut, 5 minuten) en haalt wijzigingen op met een delta-cursor. 30s-5min Alle providers, eenvoudige installaties Laag - maar quota-intensief op schaal
    IMAP IDLE (long-poll) Uw client stuurt IDLE naar de server; de server stuurt EXISTS-meldingen wanneer nieuwe e-mail arriveert. Verbinding wordt tot 29 minuten opengehouden. Onder 1 jaar Alleen IMAP-servers Hoog - één TCP-verbinding per postbus
    Webhooks (push)
    Hoe het werkt Provider stuurt een HTTP POST naar uw eindpunt wanneer een postvak verandert. Gmail gebruikt Pub/Sub; Microsoft Graph gebruikt wijzigingsmeldingen.
    Latency Onder 5 jaar
    Het beste voor Gmail, Outlook, uniforme API's zoals Unipile
    Complexiteit Mediumabonnementbeheer vereist
    Polling (gepland)
    Hoe het werkt Uw worker roept de provider API aan op een schema (elke 30 seconden, 1 minuut, 5 minuten) en haalt wijzigingen op met een delta-cursor.
    Latency 30s-5min
    Het beste voor Alle providers, eenvoudige installaties
    Complexiteit Laagmaar op schaal quota-intensief
    IMAP IDLE (long-poll)
    Hoe het werkt Uw client stuurt IDLE naar de server; de server stuurt EXISTS-meldingen wanneer nieuwe e-mail arriveert. Verbinding wordt tot 29 minuten opengehouden.
    Latency Onder 1 jaar
    Het beste voor Alleen IMAP-servers
    Complexiteit Hoogéén TCP-verbinding per postbus

    Productieaanbeveling: Gebruik webhooks als uw primaire real-time mechanisme en voer een delta-synchronisatie polling fallback (elke 5 minuten) uit om gemiste gebeurtenissen tijdens downtime op te vangen. Met de e-mail synchronisatie API van Unipile zijn beide eenmalig geconfigureerd - de uniforme email.nieuw webhook wordt geactiveerd, ongeacht of het account Gmail, Outlook of IMAP is, en een achtergrond-reconciliatieloop verwerkt gemiste gebeurtenissen automatisch.

    Beveiliging en naleving

    Beveiliging en naleving voor e-mail synchronisatie-API's

    Toegang tot gebruikersinboxen brengt aanzienlijke beveiligings- en wettelijke verplichtingen met zich mee. Hier is wat uw implementatie van de e-mailsynchronisatie-API moet aanpakken voordat u naar productie gaat.

    OAuth-bereiken - Minste Privilege

    Vraag alleen de reikwijdtes aan die uw toepassing nodig heeft. Vraag voor alleen-lezen e-mailsynchronisatie aan gmail.alleenlezen in plaats van gmail-aanpassen. Voor Microsoft Graph, aanvraag Mail.lezen in plaats van Mail.ReadWrite. Google's CASA-verificatie (vereist voor apps met meer dan 100 gebruikers) beoordeelt uw aangevraagde scopes nauwkeurig - te veel scopes vertragen de goedkeuring.

    Tokenopslag - Versleuteling in rust

    OAuth refresh tokens zijn langdurige inloggegevens die volledige toegang tot de mailbox verlenen. Ze moeten versleuteld worden opgeslagen (minimaal AES-256) en mogen nooit worden gelogd. Roteer uw token-encryptiesleutels periodiek. Een compromittering van een refresh token is gelijk aan een compromittering van het wachtwoord voor het verbonden e-mailaccount.

    AVG en datalocatie

    E-mailinhoud die wordt gesynchroniseerd van EU-gebruikers, is persoonsgegevens onder de AVG. U heeft een wettelijke grondslag voor verwerking nodig (doorgaans de expliciete toestemming van de gebruiker via OAuth), een gegevensverwerkingsovereenkomst met uw API-provider voor e-mailsynchronisatie en een duidelijk beleid voor gegevensretentie. Als uw infrastructuur in de VS is gevestigd, zorg er dan voor dat u SCC's of een equivalent overdrachtsmechanisme heeft voor EU-gegevens.

    Google CASA Verificatie

    Elke toepassing die Gmail OAuth-bereiken gebruikt met meer dan 100 gebruikers moet de Google-test voltooien CASA (Cloud Application Security Assessment). Dit is een beveiligingsbeoordeling van uw applicatie, inclusief code, infrastructuur en rechtvaardiging van OAuth-bereik. Het proces duurt 4-8 weken. Begin vroeg – falen voor CASA betekent dat alle gebruikers de toegang tot Gmail verliezen totdat u slaagt.

    Webhook Handtekening Verificatie

    Verifieer altijd de handtekening op inkomende webhook-payloads van uw e-mail synchronisatie-API. Een niet-ondertekende of onjuist geverifieerde webhook kan worden vervalst om valse e-mailgebeurtenissen in uw toepassing te injecteren. Unipile ondertekent alle webhook-leveringen met HMAC-SHA256. Verifieer de X-Unipile-Handtekening header voordat er een gebeurtenis wordt verwerkt.

    Audit Logboekregistratie

    Log elke actie die uw toepassing uitvoert op gesynchroniseerde e-mailgegevens: wie had toegang tot welke berichten, wanneer, en wat is er met de gegevens gedaan. Auditlogs zijn vereist voor SOC 2 Type II-naleving en zijn vaak het eerste waar zakelijke klanten naar vragen tijdens beveiligingscontroles. Bewaar logs minimaal 90 dagen, bij voorkeur 1 jaar.

    Veelvoorkomende valkuilen

    Veelvoorkomende valkuilen bij het bouwen van een e-mailsynchronisatie-API

    Dit zijn de meest voorkomende bugs en architectonische fouten die we zien bij implementaties van e-mailsynchronisatie-API's. Ze zijn allemaal te voorkomen met de juiste ontwerpkeuzes vooraf.

    1
    Het niet correct afhandelen van tokenvernieuwingsfouten

    Wanneer een vernieuwingstoken verloopt of wordt ingetrokken, genereert een naïeve implementatie een foutmelding en stopt de synchronisatie - in stilte. De gebruiker merkt pas dat de synchronisatie van zijn inbox is gestopt als hij merkt dat de gegevens verouderd zijn. Repareren: implementeer een 'revocation detection' laag die opvangt ongeldige_verlening fouten, markeert het gekoppelde account als opnieuw te autoriseren en informeert de gebruiker via het meldingssysteem van uw product.

    2
    Te agressief pollen en het bereiken van limieten

    Polling elke 10 seconden voor 200 gekoppelde accounts vreet de quota per project van Gmail binnen enkele uren op. Microsoft Graph begint terug te keren 429 Te veel verzoeken. Het resultaat is stille synchronisatiefouten voor alle accounts - niet alleen voor de accounts die de throttle hebben geactiveerd. Repareren: gebruik webhooks als uw primaire mechanisme met een 5-minuten polling fallback, en implementeer rate limiting per account met exponentiële backoff op alle 429 reacties.

    3
    De ruwe MIME-body opslaan in plaats van de geparseerde inhoud

    Ruwe MIME is groot, moeilijk te doorzoeken en duur om te parsen bij het lezen. Een enkele e-mail met bijlagen kan honderden kilobytes groot zijn. Repareren: Parseer de MIME-gegevens bij het binnenhalen: haal de HTML-hoofdtekst, de fallback in platte tekst, de headers en de metagegevens van bijlagen afzonderlijk eruit. Sla de binaire bestanden van bijlagen op in objectopslag (S3 of vergelijkbaar), niet in je primaire database. Dit alleen al verlaagt je opslagkosten met 60-80% voor gangbare zakelijke mailboxen.

    4
    Ontbrekende e-mail-threading tussen providers

    Gmail threadId werkt alleen binnen Gmail. Als uw app een conversatie toont die een Gmail-account en een Outlook-account omvat (bijvoorbeeld een reactie verzonden vanaf een andere mailbox), zijn de native conversatie-ID's nutteloos. Repareren: bouw een cross-provider threading engine gebaseerd op de Bericht-ID, In-Reply-Toen Referenties headers. Normalise onderwerpregels (verwijder Re:/Fwd: voorvoegsels) als fallback voor e-mails die deze headers missen.

    5
    Synchronisatiecursor kwijt na herstarten

    Delta sync is afhankelijk van een opgeslagen cursor: die van Gmail. geschiedenisId, van Microsoft Graph's deltaLink, IMAP's MODSEQ. Als je synchronisatiewerker opnieuw opstart en de cursor alleen in het geheugen wordt opgeslagen, verlies je je positie in de stream van wijzigingen. De volgende synchronisatie begint opnieuw, waardoor alle historische berichten worden gedupliceerd of de tussenliggende periode wordt gemist. Repareren: persist de cursor naar uw database na elke succesvolle sync-cyclus, atomair met de laatste batch van verwerkte wijzigingen.

    6
    De onderscheiding tussen verzonden en ontvangen e-mails negerend

    Voor CRM-toepassingen heb je zowel inkomende (ontvangen) als uitgaande (verzonden) e-mails nodig om een volledige communicatietijdlijn op te bouwen. Het INBOX-label van Gmail dekt alleen ontvangen e-mail; je hebt ook VERZONDEN. Microsoft Graph vereist het opvragen van de Verzonden items map apart. IMAP vereist dat u de map selecteert Verzonden map expliciet. Repareren: synchroniseer alle relevante mappen bij het instellen van een account, niet alleen INBOX, en map providerspecifieke mapnamen toe aan genormaliseerde typen in uw gegevensmodel.

    FAQ

    Veelgestelde Vragen over API's voor E-mail Synchronisatie

    De meest gestelde vragen van ontwikkelaars bij het voor de eerste keer implementeren van een e-mailsynchronisatie-API.

    1
    Wat is een e-mail synchronisatie API?
    +
    Een e-mail synchronisatie API is een programmatische interface die continu de mailbox van een gebruiker spiegelt naar uw applicatie. Het leest inkomende en uitgaande berichten, volgt statuswijzigingen (gelezen/ongeld, mapverplaatsingen, verwijderingen) en levert real-time meldingen via webhooks wanneer nieuwe e-mails arriveren. In tegenstelling tot een transactionele e-mail API (die systeemberichten verzendt), vereist een e-mail sync API dat de gebruiker autoriseert voor toegang tot hun bestaande inbox via OAuth.
    2
    Wat is het verschil tussen een e-mail synchronisatie API en een transactionele e-mail API?
    +
    Een e-mail synchronisatie-API leest en spiegelt de bestaande mailbox van een gebruiker (Gmail, Outlook, IMAP) naar uw applicatie met behulp van OAuth. Een transactionele e-mail-API (zoals SendGrid of Mailgun) verzendt systeemgegenereerde e-mails vanuit uw eigen domein met behulp van een API-sleutel, zonder toegang tot de inbox van de gebruiker. Ze dienen tegengestelde doelen en richten zich op compleet verschillende markten. Unipile valt in de categorie e-mail synchronisatie - het is geen transactionele verzender.
    3
    Welke e-mailproviders ondersteunt de e-mail synchronisatie-API van Unipile?
    +
    De e-mail synchronisatie-API van Unipile ondersteunt drie providers: Gmail (Google), Outlook / Microsoft 365 (Microsoft Graph - omvat zowel persoonlijke Outlook als zakelijke M365 / Exchange Online), en IMAP (waaronder Exchange, ProtonMail, Zoho, Fastmail en aangepaste domeinen). Alle drie zijn toegankelijk via hetzelfde uniforme API-eindpunt.
    4
    Hoe werkt delta synchronisatie in een e-mail synchronisatie-API?
    +
    Delta-synchronisatie betekent dat alleen de wijzigingen worden opgehaald sinds de laatst bekende positie in de wijzigingsstroom van de mailbox, in plaats van elke keer alle berichten opnieuw op te halen. Gmail gebruikt een geschiedenisId cursor met de gebruikers.geschiedenis.lijst endpoint. Microsoft Graph gebruikt een deltaLink teruggegeven door de /berichten/delta eindpunt. IMAP gebruikt de MODSEQ waarde van de CONDSTORE-extensie. Een uniforme e-mailsynchronisatie-API normaliseert deze drie verschillende mechanismen achter één consistente interface.
    5
    Wat is het verschil tussen polling en webhooks voor e-mail synchronisatie?
    +
    Pollen betekent dat je werknemer de e-mail-API op een schema aanroept (elke 30 seconden, 1 minuut, etc.) om te controleren op nieuwe berichten. Webhooks zijn push-gebaseerd: de provider (of uniforme API) stuurt onmiddellijk een HTTP POST naar je endpoint wanneer er een nieuwe e-mail binnenkomt. Webhooks zorgen voor bijna realtime synchronisatie (latentie van minder dan 5 seconden), terwijl pollen latentie introduceert die gelijk is aan je pollinterval. In productie is de beste methode webhooks als primair, met een delta-sync polling als fallback voor gemiste gebeurtenissen.
    6
    Hoe lang duurt het om e-mail synchronisatie met Unipile in te stellen?
    +
    De meeste ontwikkelaars hebben een werkende e-mailsynchronisatie integratie die binnen één dag draait. De belangrijkste stappen zijn: maak een Unipile-account aan (gratis, geen creditcard), gebruik de gehoste OAuth-stroom om een gebruiker hun Gmail- of Outlook-account te laten verbinden, roep GET /emails met de account_id om gesynchroniseerde berichten op te halen, en registreer een webhook-eindpunt om realtime te ontvangen email.nieuw events. Unipile regelt automatisch OAuth, tokenvernieuwing, delta-synchronisatie en webhook-levering.
    7
    Welke OAuth-bereiken heb ik nodig voor e-mailsynchronisatie?
    +
    Voor Gmail alleen-lezen synchronisatie, verzoek gmail.alleenlezen. Als u berichten als gelezen wilt markeren of wilt verplaatsen, vraagt u gmail-aanpassen. Voor Microsoft Graph, aanvraag Mail.lezen voor alleen-lezen toegang of Mail.ReadWrite voor volledige toegang. Vraag altijd de minimale scopes aan die je applicatie daadwerkelijk nodig heeft - Google's CASA-verificatie (vereist voor apps met 100+ gebruikers) beoordeelt de scope-rechtvaardiging nauwkeurig, en te veel scopes kunnen je goedkeuring vertragen.
    8
    Is er een gratis e-mail synchronisatie API-laag beschikbaar?
    +
    Ja. Unipile biedt een gratis e-mail API-niveau dat toegang geeft tot alle drie de providers (Gmail, Outlook, IMAP) zonder dat er een creditcard nodig is. De gratis laag is geschikt voor ontwikkeling, testen en vroege productie met een klein aantal gekoppelde accounts. Zie de Unipile-prijzenpagina of de gratis e-mail API-documentatie voor de huidige limieten.
    9
    Hoe ga ik om met verlopen OAuth-tokens in een e-mail-sync-API?
    +
    Toegangstokens verlopen (meestal 1 uur voor zowel Google als Microsoft). Uw synchronisatie-infrastructuur moet detecteren 401 Niet toegestaan responsies, gebruik de opgeslagen vernieuwingstoken om een nieuwe toegangstoken te verkrijgen en probeer het mislukte verzoek transparant opnieuw. Vernieuwingstokens zelf kunnen worden ingetrokken. Wanneer intrekking wordt gedetecteerdongeldige_verlening (fout), markeer het account als opnieuw te moeten worden geautoriseerd en stel de gebruiker op de hoogte. Unipile beheert automatisch het gehele tokenlevenscyclusbeheer voor gekoppelde accounts.
    10
    Wat is IMAP IDLE en hoe maakt het realtime e-mailsynchronisatie mogelijk?
    +
    IMAP IDLE (RFC 2177) is een commando dat een IMAP-sessie in pushmodus zet: in plaats van dat uw client herhaaldelijk pollt, stuurt de server ongevraagd BESTAAT meldingen wanneer nieuwe berichten arriveren. Dit maakt synchronisatie van de inbox bijna in realtime mogelijk (met minder dan 1 seconde latentie) zonder constant te hoeven controleren. IDLE-verbindingen moeten elke 29 minuten worden vernieuwd om time-outs van de server te voorkomen. IDLE werkt met elke IMAP-server die dit ondersteunt, waaronder de meeste moderne mailservers zoals corporate Exchange, Gmail via IMAP en Outlook via IMAP.
    nl_NLNL