5 Producten die werken op een E-mail API - en Waarom
CRM-verrijking, ATS-kandidaattracking, sales engagement, helpdesk-inboxen, AI-assistenten - elk van deze producten moet e-mails lezen en verzenden namens geauthenticeerde gebruikers. Deze gids laat precies zien hoe ze dat doen, met echte codevoorbeelden, zodat u dit in uren, niet in weken kunt bouwen.
const response = wacht op fetch(
`/api/v1/emails?account_id=${accountId}`,
{ headers: {
'X-API-KEY': process.env.UNIPILE_KEY
}}
);
const { e-mails } = wacht op antwoord.json();
// Automatisch inloggen op contacttijdlijn
logToCRM(e-mails, contactId);
Wat Kun Je Bouwen Met Een E-mail-API?
Een e-mail-API voor gebruikerssynchronisatie laat je product lez, synchroniseer en verzend e-mails namens geauthenticeerde gebruikers, toegang krijgen tot hun echte inboxen via OAuth. De vijf belangrijkste e-mail-API-toepassingen zijn: CRM-verrijking (log elke prospect e-mail automatisch), ATS kandidaatvolgsysteem (thread synchronisatie per kandidaat), verkoopbetrokkenheid (antwoorddetectie en verzenden vanaf een echte mailbox), klantenservice (geïntegreerd e-mailinbox met meerdere postbussen), en AI e-mailagenten (toegang tot LLM met scope om ontwerpen en triage te maken). Elk van deze draait op hetzelfde onderliggende patroon: lezen + synchroniseren + verzenden namens de geauthenticeerde gebruiker.
| Verticaal | E-mail vacature | API-patroon | Primaire aanbieders |
|---|---|---|---|
| CRM | Contact verrijken, draad automatisch loggen | lezen + synchroniseren | Gmail, Outlook, IMAP |
| ATS/Werving | Volg kandidaat-draad, deel weergave | synchroniseren + lezen | Gmail, Outlook, IMAP |
| Verkoopbetrokkenheid | Antwoorddetectie, verzenden vanuit de postbus van de vertegenwoordiger | synchroniseren + verzenden | Gmail, Outlook, IMAP |
| Klantenservice | Gedeelde inbox, ticket uit thread | lees + verzenden | Gmail, Outlook, IMAP |
| AI E-mail Agent | Triage, concept, samenvatten namens | lezen + verzenden (scoped) | Gmail, Outlook, IMAP |
Niet wat je zoekt? Er zijn twee categorieën e-mail-API's: transactioneel (SendGrid, Mailgun, u bent eigenaar van het verzenddomein, ontvangers hebben zich nooit aangemeld voor uw product) en gebruikerssynchronisatie (dit artikel). User-sync betekent OAuth-delegatie, uw product handelt namens geauthenticeerde gebruikers die toegang krijgen tot hun eigen inboxen. De vijf gebruiksgevallen hieronder vallen allemaal onder user-sync. Als u bulk-nieuwsbrieven vanaf uw eigen domein wilt verzenden, is dit niet uw gids.
E-mail-API voor CRM
Een CRM dat gebruikmaakt van een e-mail-API kan elke e-mailconversatie tussen een vertegenwoordiger en een prospect automatisch vastleggen, rechtstreeks op het contactrecord - zonder te kopiëren en plakken. De e-mail-API leest de inbox van de gebruiker namens de geauthenticeerde vertegenwoordiger, koppelt e-mailthreads aan bestaande contacten op basis van e-mailadres en schrijft realtime naar de CRM-tijdlijn.
Het patroon achter e-mail API voor CRM is lezen + synchroniseren + verzenden - allemaal namens de geauthenticeerde gebruiker. De vertegenwoordiger koppelt eenmalig hun Gmail- of Outlook-account via OAuth. Daarna wordt elke inkomende en uitgaande e-mail met een bekende contactpersoon automatisch vastgelegd - geen BCC-doorsturing, geen browser-extensie, geen handmatige logging.
// 1. E-mails ophalen voor een contactpersoon
namens geauthentiseerde vertegenwoordiger
GET /api/v1/emails
?account_id={rep_account_id}
&van_e_mailadres={contact_email}
Autorisatie: X-API-KEY {key}
Reactie
{
"voorwerp": "AccountEmaillijst",
"items": [
{
"id": "em_01abc",
"onderwerp": "Re: Opvolging",
"van": "contact@acme.com",
"datum": "2026-06-05"
}
]
}E-mail API voor ATS / Wervingssoftware
Een ATS dat een e-mail-API integreert, krijgt een compleet, automatisch gesynchroniseerd overzicht van elke e-mailconversatie met elke kandidaat – bij alle recruiters, alle e-mailproviders. Recruiters koppelen hun accounts eenmalig; vanaf dat moment wordt elke e-mailthread automatisch gekoppeld aan het kandidaatprofiel.
De e-mail API voor ATS Het gebruiksscenario richt zich op synchronisatie en zichtbaarheid. Recruiters hebben doorgaans verschillende recruiters die verschillende e-mailaccounts beheren, Gmail voor de ene, Outlook voor de andere. De e-mail-API leest elk gekoppeld account namens de geauthenticeerde recruiter en toont alle e-mailthreads met het e-mailadres van een kandidaat in een enkele, uniforme tijdlijn binnen het ATS.
De E-mail API gebruiksscenario Dit is bijzonder waardevol voor teams met meerdere providers. Recruiters bij grote bedrijven maken vaak gebruik van zowel Gmail- als Outlook-accounts. Een uniforme e-mail-API ondersteunt beide met een enkele integratie, zodat de ATS-ontwikkelaar één code pad schrijft - geen twee. Voor het volledige technische patroon voor het lezen van inboxgegevens, zie de lees e-mail API gids. Voor realtime synchronisatiepatronen, zie de e-mailsynchronisatie API-handleiding.
Samenvatting van het ATS e-mail API-patroon: Link recruiteraccounts via OAuth (Gmail, Outlook, of IMAP). Synchroniseer alle inkomende en uitgaande threads per kandidaatadres. Bied een uniforme tijdlijn aan in de ATS-gebruikersinterface. Stuur optioneel antwoorde-mails vanuit de ATS namens de echte mailbox van de recruiter - geen BCC-doorsturing, geen e-mailaliassen, geen "van noreply@jouwapp.com".
E-mail API voor verkoopinzet
Sales engagement platforms gebruiken een e-mail-API om te detecteren wanneer een potentiële klant reageert en de volgende stap in een reeks automatisch te activeren - follow-ups pauzeren, de verkoper op de hoogte stellen, de dealstatus verplaatsen. Cruciaal is dat uitgaande e-mails worden verzonden vanuit de echte mailbox van de verkoper, niet vanuit een gedeeld platformdomein, wat de afleverbaarheid en de identiteit van de afzender behoudt.
De e-mail-API voor verkoopbetrokkenheid het patroon is synchroniseren + verzenden, op basis van gebruiker. Elke vertegenwoordiger koppelt eenmalig hun Gmail- of Outlook-account. Elke e-mail in een actieve reeks wordt verzonden vanaf het echte adres van die vertegenwoordiger. Wanneer een antwoord arriveert, detecteert de synchronisatiemotor de thread-ID, koppelt deze aan een open reeks en activeert de juiste automatisering. Dit is een beslissing aan de kant van de klant - het platform faciliteert de actie; de cadans en het volume blijven onder controle van het verkoopteam.
Dit e-mail API gebruiksscenario is de ruggengraat van tools zoals outreachplatforms en SaaS voor verkooppautomatisering. Het voordeel van afleverbaarheid is fundamenteel: e-mails die worden verzonden vanaf rep@company.com via de daadwerkelijke Gmail- of Outlook-mailbox van de vertegenwoordiger, erven de verzendreputatie van het domein. E-mails die vanaf een gedeeld platformdomein worden verzonden, doen dit niet. Het volledige verzendpatroon wordt gedocumenteerd in de e-mail versturen API-handleiding.
Waarom het ertoe doet voor leverbaarheid: Platform-domein verzending (van sequences@platform.com) scheidt de reputatie van de afzender van het domein van de afzender. User-sync verzending routeert elke e-mail via de mailbox van de geauthenticeerde gebruiker - Gmail SMTP of Outlook Graph - zodat de afleverbaarheid is gekoppeld aan het domein van de afzender, niet aan dat van het platform. Dit is een structureel voordeel dat geen enkele transactionele e-mail-API kan repliceren.
E-mail API voor Klantenservice / Helpdesk
Een helpdesk gebouwd op een e-mail API aggregeert elke supportmailbox - support@, billing@, enterprise@ - in één uniforme inbox. Nieuwe e-mails creëren automatisch tickets. Antwoorden worden verzonden vanaf het oorspronkelijke mailboxadres. De supportmedewerker verlaat nooit de helpdeskinterface om Outlook of Gmail te openen.
De E-mail API voor klantenservice Het gebruiksscenario is voornamelijk lezen + verzenden, met een sterke vereiste voor threading. De meeste helpdesks beheren meerdere adressen van meerdere providers: een team gebruikt Gmail, een ander Outlook, en een derde heeft mogelijk een IMAP-only legacy inbox. Een verenigde e-mail API leest alle gekoppelde accounts als een enkele stream, waarbij de threading context behouden blijft, zodat agenten in de juiste thread kunnen reageren met de juiste afzenderidentiteit.
Dit E-mail API gebruiksscenario is hoe moderne helpdesk SaaS-producten – vooral degene die zich positioneren tegenover verouderde tools gebouwd op e-mail-only plug-ins – zich onderscheiden. Het belangrijkste onderscheidende kenmerk is draadgetrouwheid: e-mails stromen via het echte SMTP/Graph-kanaal van de inbox-eigenaar, zodat antwoorden op het juiste onderwerp landen aan de kant van de klant, en niet als een losgekoppeld bericht van een generiek platformadres. Zie voor de volledige technische handleiding die alle drie de providers dekt, de Handleiding voor e-mail-API.
Bouw je support inbox-integratieE-mail API voor AI E-mail Agenten / Assistenten
AI-e-mailagents gebruiken een e-mail-API om een groot taalmodel toegang te geven, met een specifieke scope en namens de gebruiker, tot iemands echte inbox – ze lezen e-mailthreads om antwoorden te formuleren, berichten te sorteren, lange e-mailketens samen te vatten en optioneel antwoorden te verzenden na menselijke goedkeuring. Het model verwerkt nooit OAuth-gegevens; de e-mail-API abstraheert de inbox als een duidelijke gestructureerde stroom.
Dit is de nieuwste E-mail API gebruiksscenario en de snelst groeiende in 2026. AI-assistenten die zijn ingebed in productiviteitstools, verkooptolls en CRM-producten hebben alle drie dezelfde dingen nodig: lees toegang tot de inbox voor het ophalen van context, gestructureerde e-mailgegevens voor het aansturen (onderwerp, van, inhoud, thread-ID), en een optioneel verzendkanaal voor bevestigde concepten. De e-mail-API biedt deze drie in één enkele integratie voor Gmail, Outlook en IMAP, namens de geauthenticeerde gebruiker.
Gespecificeerde toegang en gegevensbehandeling: AI-e-mailagenten gebouwd op een user-sync e-mail-API hebben alleen toegang tot de inbox van de geauthenticeerde gebruiker - nooit verder dan dat bereik. De e-mail-API fungeert als een onafhankelijke technische tussenpersoon, waardoor gestructureerde gegevens naar de LLM-laag worden doorgestuurd zonder een parallelle kopie van de e-mails van de gebruiker op te slaan. De reikwijdte van gegevensbehandeling, retentie en toestemming blijven een beslissing aan de kant van de klant. Dit is de juiste architectuur voor AI-agenten die namens echte gebruikers opereren, zonder een datamart te worden.
Bij het bouwen van AI-e-mailagents op schaal moet u ook rekening houden met de realiteit van meerdere providers: uw gebruikers hebben Gmail-, Outlook- en IMAP-accounts. Een uniforme e-mail-API normaliseert de inbox-stream naar een consistente structuur - thread_id, onderwerp, van, naar, body, datum - ongeacht de provider. Uw LLM-prompt template blijft hetzelfde voor alle drie. Voor de volledige technische gids over de e-mailintegratielaag voor AI-producten, zie de E-mail API-handleiding voor ontwikkelaars. Voor de bredere architectuur van multi-channel AI-agenten (het toevoegen van LinkedIn, WhatsApp en andere kanalen aan dezelfde agent), behandelt de aankomende gids over de multi-channel API voor AI-agenten de volledige stack.
Begin met het bouwen van uw AI-e-mailagentTransactioneel versus User-Sync: Welk gebruiksscenario is van toepassing op u?
Als de vijf e-mail API-toepassingen hierboven niet aansluiten bij uw behoeften, bevindt u zich mogelijk in de verkeerde categorie. E-mail API's vallen uiteen in twee fundamenteel verschillende markten, transactioneel en user-sync, en deze overlappen niet. Dit korte gedeelte vertelt u aan welke kant u staat, zodat u niet de verkeerde tools evalueert.
| Afmeting | API voor transactionele e-mail | User-sync e-mail API (dit artikel) |
|---|---|---|
| Wie is de eigenaar van het verzendende domein | Jij (het platform) | De gebruiker (hun Gmail / Outlook) |
| Typische afzenders | noreply@yourapp.com | user@theirdomain.com |
| OAuth vereist | Geen | Ja |
| Lees / synchroniseer gebruikersinbox | Geen | Ja |
| Gebruiksscenario's | Meldingen, ontvangstbewijzen, marketing | CRM, ATS, verkoop, ondersteuning, AI-agenten |
| Voorbeeldproviders | SendGrid, Mailgun, Resend | Gmail API, MS Graph, IMAP, Unipile |
Als uw product meldingen, ontvangstbewijzen of marketing-e-mails van een domein dat u bezit verzendt, dan is dat de transactionele markt, en SendGrid, Mailgun of Resend zijn de juiste tools. Als uw product namens gebruikers toegang nodig heeft tot hun echte inboxen, hun e-mails moet lezen, hun threads moet synchroniseren, of vanaf hun werkelijke adres moet verzenden, dan is dat user-sync, en de vijf e-mail API gebruiksscenario's hierboven staat precies wat u aan het bouwen bent. Voor een diepere analyse van wanneer u welke aanpak moet kiezen, zie de volledige gids over sync vs transactionele e-mail API's.
Data, Privacy en Platformverantwoordelijkheid
Elk e-mail API-gebruiksscenario in dit artikel omvat toegang tot echte gebruikersinboxen via OAuth. Voordat u bouwt, moet u begrijpen hoe Unipile opereert als tussenpersoon, wat gegevensverwerking in de praktijk betekent en waar de platformverantwoordelijkheid ligt.
Unipile onderhoudt geen parallelle kopie van de e-mails van uw gebruikers, onafhankelijk van hun mailbox. Toegang is beperkt tot de geverifieerde gebruiker'het account, beperkt tot de sessie en de via OAuth toegekende machtigingen. Er wordt geen e-mailarchief opgebouwd buiten de eigen provider van de gebruiker (Gmail, Outlook, IMAP). De reikwijdte van de gegevensverwerking, retentiebeleid en mechanismen voor toestemming van de gebruiker blijven de verantwoordelijkheid van uw product als de verwerkingsverantwoordelijke.
Unipile fungeert als een onafhankelijke technische tussenpersoon tussen uw product en de e-mailprovider. Elke e-mailbewerking - lezen, synchroniseren, verzenden - wordt uitgevoerd namens de eigenaar van het gekoppelde account, met hun eigen OAuth-gegevens. Unipile is niet gelieerd aan, goedgekeurd door of gesponsord door Google of Microsoft. Er worden geen gegevens gedeeld tussen gebruikers. Elk gekoppeld account is geïsoleerd.
Unipile geeft de snelheidsbeperkingen en toegangscontroles van de onderliggende e-mailprovider (Google, Microsoft, IMAP-server) weer. De frequentie van API-aanroepen, de cadans van synchronisaties en het volume van e-mails dat per account wordt verzonden, blijven een beslissing aan klantzijde. Uw product is verantwoordelijk voor het respecteren van providerquota's en toepasselijke regelgeving (AVG, CCPA). Unipile is SOC 2 gecertificeerd en AVG-compliant als infrastructuurlaag.
Unipile is niet gelieerd aan, goedgekeurd door, of gesponsord door Google of Microsoft Corporation. Gmail en Outlook zijn handelsmerken van hun respectievelijke eigenaren. Google is niet gelieerd aan Unipile. Microsoft is niet gelieerd aan Unipile. Gebruik van deze platforms via de API van Unipile is onderworpen aan de servicevoorwaarden en het acceptabele gebruiksbeleid van de respectievelijke platforms.
E-mail API Gebruiksscenario's - Veelgestelde Vragen
Veelgestelde vragen over e-mail API-gebruiksscenario's, OAuth-toegang tot de inbox en bouwen op e-mail API's voor gebruikerssynchronisatie.
Een e-mail-API laat softwareproducten e-mails lezen, synchroniseren en verzenden namens geauthenticeerde gebruikers - toegang krijgen tot hun echte Gmail-, Outlook- of IMAP-inboxen via OAuth. Kern e-mail API gebruiksscenario's inclusief CRM-verrijking, ATS-kandidaatvolging, verkoopactiviteitensequentieautomatisering, geünificeerde helpdesk-inboxen en AI-e-mailagenten. Dit is onderscheidend van transactionele e-mail-API's (SendGrid, Mailgun) die bulkberichten verzenden vanaf een door het platform-domein en die geen OAuth-inbox-toegang omvatten.
Een CRM maakt gebruik van een e-mailapi om automatisch elke e-mailconversatie tussen een vertegenwoordiger en een potentiële klant vast te leggen op het contactrecord - geen handmatig kopiëren en plakken, geen BCC doorsturen vereist. De e-mail API voor CRM leest de inbox van de vertegenwoordiger namens de geverifieerde gebruiker, koppelt threads aan contact-e-mailadressen en schrijft in realtime naar de CRM-tijdlijn. Het maakt ook het verzenden van e-mails vanuit de CRM mogelijk met behulp van de mailbox van de vertegenwoordiger, zodat antwoorden vanaf hun echte adres komen - cruciaal voor antwoordsnelheden en afleverbaarheid.
ATS-platforms gebruiken de e-mail API voor ATS om alle threads tussen recruiters en kandidaten te synchroniseren. Elke recruiter koppelt eenmalig hun Gmail- of Outlook-account via OAuth. De API leest alle e-mails van of naar het adres van elke kandidaat van alle recruiteraccounts en koppelt deze aan het kandidaatprofiel. Dit geeft het volledige team gedeelde zichtbaarheid zonder dat iemand toegang nodig heeft tot de mailbox van een collega. Sommige ATS-producten combineren dit met een Kalender API om discussiethreads over het plannen van sollicitatiegesprekken te analyseren en automatisch afspraken aan te maken.
Ja. Je kunt de Gmail- of Outlook-inbox van een gebruiker synchroniseren met een e-mail-API die OAuth-delegatie ondersteunt. De gebruiker authenticeert eenmalig via Google- of Microsoft OAuth, waardoor je app toegang krijgt namens hun account. De API biedt vervolgens eindpunten om e-mails op te sommen, thread-inhoud op te halen, nieuwe berichten te synchroniseren via webhooks en vanuit de mailbox van de gebruiker te verzenden. Een uniforme e-mail-API zoals Unipile dekt Gmail, Outlook en IMAP met één enkele integratie - zie de Handleiding voor e-mail-API voor de volledige technische doorloop.
AI e-mailassistenten hebben toegang tot e-mails via een e-mail-API die biedt scoped, on-behalf-of inbox toegang voor de geauthenticeerde gebruiker. De e-mail-API haalt gestructureerde gegevens op (onderwerp, van, naar, body, thread-ID) en geeft deze als context door aan het LLM. Het model genereert vervolgens een conceptantwoord, samenvatting of triage-actie. De e-mail-API beheert OAuth en normaliseert providerverschillen (Gmail, Outlook, IMAP), zodat de AI-laag een consistente gestructureerde feed ontvangt, ongeacht de provider van de gebruiker. Het model verwerkt nooit inloggegevens of ruwe OAuth-tokens.
Ja. Het lezen van de inbox van een gebruiker vereist OAuth-autorisatie. Voor Gmail betekent dit Google OAuth 2.0 met de juiste Gmail API-bereiken. Voor Outlook betekent dit Microsoft OAuth met Microsoft Graph-machtigingen. Voor IMAP is XOAUTH2 de moderne standaard (basisauthenticatie is afgebouwd door grote providers, waaronder Google en Microsoft). OAuth zorgt ervoor dat de gebruiker expliciet toestemming geeft voor toegang tot de inbox en dat de machtigingsscope beperkt is tot wat is goedgekeurd. Een uniforme e-mail-API handelt deze OAuth-stroom af voor alle drie de providers.
Meest e-mailintegratie voor SaaS producten vallen in een van de vijf user-sync use cases in dit artikel: CRM (gesprekken loggen), ATS (kandidaten volgen), sales (verzenden + detectie van antwoorden), support (uniforme inbox), of AI (context ophalen). De onderliggende architectuurbeslissing - of direct te bouwen op de Gmail API / Microsoft Graph / IMAP of om een uniforme abstractielaag te gebruiken - wordt in detail besproken in de E-mail API voor SaaS-handleiding, inclusief architectuurpatronen, verborgen kosten en de build-vs-buy-beslissing.
Nee, Unipile is niet gelieerd aan, goedgekeurd door, of gesponsord door Google of Microsoft. Unipile is een onafhankelijke technische tussenpersoon dat een uniforme API-laag biedt over Gmail (Google), Outlook (Microsoft) en IMAP. De toegang tot elke provider wordt beheerst door de respectieve servicevoorwaarden van het platform. Unipile is SOC 2-gecertificeerd en GDPR-conform als infrastructuurlaag. Uw product blijft verantwoordelijk voor de toestemming van de gebruiker, de reikwijdte van de gegevensverwerking en naleving van de toepasselijke regelgeving inzake gegevensbescherming.
Nog steeds vragen over e-mail API gebruiksscenario's? Ons team staat klaar om u te helpen.