LinkedIn
Instagram
WhatsApp
Telegram
Gmail
Outlook
Google Calendar
Join Slack Community5 Products That Run on an Email API - and Why
CRM enrichment, ATS candidate tracking, sales engagement, helpdesk inboxes, AI assistants - each of these products needs to read and send emails on behalf of authenticated users. This guide shows exactly how they do it, with real code patterns, so you can build the same in hours, not weeks.
const response = await fetch(
`/api/v1/emails?account_id=${accountId}`,
{ headers: {
'X-API-KEY': process.env.UNIPILE_KEY
}}
);
const { emails } = await response.json();
// Auto-log to contact timeline
logToCRM(emails, contactId);
What Can You Build with an Email API?
An email API for user-sync lets your product read, sync, and send emails on behalf of authenticated users, accessing their real inboxes via OAuth. The five core email API use cases are: CRM enrichment (auto-log every prospect email), ATS candidate tracking (thread sync per applicant), sales engagement (reply detection and send from real mailbox), customer support (unified multi-mailbox inbox), and AI email agents (scoped LLM access to draft and triage). Every one of these runs on the same underlying pattern: read + sync + send on behalf of the authenticated user.
| Vertical | Email job | API pattern | Primary providers |
|---|---|---|---|
| CRM | Enrich contact, auto-log thread | read + sync | Gmail, Outlook, IMAP |
| ATS / Recruiting | Track candidate thread, share view | sync + read | Gmail, Outlook, IMAP |
| Sales Engagement | Reply detection, send from rep mailbox | sync + send | Gmail, Outlook, IMAP |
| Customer Support | Unified inbox, ticket from thread | read + send | Gmail, Outlook, IMAP |
| AI Email Agent | Triage, draft, summarize on behalf | read + send (scoped) | Gmail, Outlook, IMAP |
Not what you are looking for? There are two categories of email API: transactional (SendGrid, Mailgun, you own the sending domain, recipients never opted into your product) and user-sync (this article). User-sync means OAuth delegation, your product acts on behalf of authenticated users accessing their own inboxes. The five use cases below all belong to user-sync. If you need to send bulk newsletters from your own domain, this is not your guide.
Email API for CRM
A CRM that uses an email API can automatically log every email exchanged between a rep and a prospect directly onto the contact record - without any copy-paste. The email API reads the user's inbox on behalf of the authenticated rep, matches threads to existing contacts by email address, and writes to the CRM timeline in real time.
The pattern behind email API for CRM is read + sync + send - all on-behalf-of the authenticated user. The rep links their Gmail or Outlook account once via OAuth. After that, every inbound and outbound email with a known contact is automatically captured - no BCC forwarding, no browser extension, no manual logging.
// 1. Fetch emails for a contact
// on behalf of authenticated rep
GET /api/v1/emails
?account_id={rep_account_id}
&from_email={contact_email}
Authorization: X-API-KEY {key}
// Response
{
"object": "AccountEmailsList",
"items": [
{
"id": "em_01abc",
"subject": "Re: Follow-up",
"from": "contact@acme.com",
"date": "2026-06-05"
}
]
}Email API for ATS / Recruiting Software
An ATS that integrates an email API gains a complete, auto-synced view of every email conversation with each candidate - across all recruiters, all email providers. Recruiters link their accounts once; from that point on, every email thread is automatically matched to the candidate profile.
The email API for ATS use case centers on sync and visibility. Recruiting teams typically have several recruiters working different email accounts, Gmail for one, Outlook for another. The email API reads each linked account on behalf of the authenticated recruiter and surfaces all threads involving a candidate's email address in a single unified timeline inside the ATS.
The email API use case here is particularly valuable for multi-provider teams. Recruiters at enterprise companies often span both Gmail and Outlook accounts. A unified email API handles both with a single integration, so the ATS developer writes one code path - not two. For the full technical pattern on reading inbox data, see the read email API guide. For real-time sync patterns, see the email sync API guide.
ATS email API pattern summary: Link recruiter accounts via OAuth (Gmail, Outlook, or IMAP). Sync all inbound and outbound threads per candidate address. Expose a unified timeline in the ATS UI. Optionally send reply emails from the ATS on behalf of the recruiter's real mailbox - no BCC forwarding, no email aliases, no "from noreply@yourapp.com".
Email API for Sales Engagement
Sales engagement platforms use an email API to detect when a prospect replies and automatically trigger the next step of a sequence - pause follow-ups, notify the rep, move the deal stage. Crucially, outgoing emails are sent from the rep's real mailbox, not a shared platform domain, which preserves deliverability and sender identity.
The email API for sales engagement pattern is sync + send, on a per-user basis. Each rep links their Gmail or Outlook account once. Every email in an active sequence is sent from that rep's real address. When a reply arrives, the sync engine detects the thread ID, matches it to an open sequence, and fires the appropriate automation. This is a customer-side decision - the platform relays the action; the cadence and volume remain under the sales team's control.
This email api use case is the backbone of tools like outreach platforms and sales automation SaaS. The deliverability advantage is fundamental: emails sent from rep@company.com via the rep's actual Gmail or Outlook mailbox inherit the domain's sending reputation. Emails sent from a shared platform domain do not. The full send pattern is documented in the send email API guide.
Why it matters for deliverability: Platform-domain sending (from sequences@platform.com) splits sender reputation from the rep's domain. User-sync sending routes each email through the authenticated user's actual mailbox - Gmail SMTP or Outlook Graph - so deliverability is tied to the rep's domain, not the platform's. This is a structural advantage that no transactional email API can replicate.
Email API for Customer Support / Helpdesk
A helpdesk built on an email API aggregates every support mailbox - support@, billing@, enterprise@ - into a single unified inbox. New emails automatically create tickets. Replies are sent from the original mailbox address. The support agent never leaves the helpdesk interface to go open Outlook or Gmail.
The email API for customer support use case is primarily read + send, with a strong threading requirement. Most helpdesks manage multiple addresses across multiple providers: one team uses Gmail, another uses Outlook, a third might have an IMAP-only legacy inbox. A unified email API reads all linked accounts as a single stream, preserving thread context so agents can reply in-thread with the correct sender identity.
This email API use case is how modern helpdesk SaaS products - especially those positioning against legacy tools built on email-only plugins - differentiate themselves. The key differentiator is thread fidelity: emails flow through the real SMTP/Graph channel of the inbox owner, so replies land in the correct thread on the customer's end, not as a disconnected message from a generic platform address. For the full technical guide covering all three providers, see the Email API Guide.
Build your support inbox integrationEmail API for AI Email Agents / Assistants
AI email agents use an email API to give a large language model scoped, on-behalf-of access to a user's real inbox - reading threads to draft replies, triaging messages, summarizing long email chains, and optionally sending responses after human review. The model never handles OAuth credentials; the email API abstracts the inbox as a clean structured stream.
This is the newest email API use case and the fastest-growing in 2026. AI assistants embedded in productivity tools, sales tools, and CRM products all need the same three things: inbox read access for context retrieval, structured email data for prompting (subject, from, body, thread ID), and an optional send channel for confirmed drafts. The email API provides all three in a single integration across Gmail, Outlook, and IMAP, on behalf of the authenticated user.
Scoped access and data handling: AI email agents built on a user-sync email API only access the inbox of the authenticated user - never beyond that scope. The email API acts as an independent technical intermediary, relaying structured data to the LLM layer without storing a parallel copy of the user's emails. Data handling scope, retention, and consent remain a customer-side decision. This is the correct architecture for AI agents operating on behalf of real users without becoming a data warehouse.
When building AI email agents at scale, you also need to handle the multi-provider reality: your users will have Gmail, Outlook, and IMAP accounts. A unified email API normalizes the inbox stream into a consistent structure - thread_id, subject, from, to, body, date - regardless of provider. Your LLM prompt template stays the same for all three. For the full technical guide on the email integration layer for AI products, see the Email API Guide for Developers. For the broader architecture of multi-channel AI agents (adding LinkedIn, WhatsApp, and other channels to the same agent), the upcoming guide on multi-channel API for AI agents covers the full stack.
Start building your AI email agentTransactional vs User-Sync: Which Use Case Are You In?
If the five email API use cases above do not match your need, you may be in the wrong category entirely. Email APIs split into two fundamentally different markets, transactional and user-sync, and they do not overlap. This short section tells you which side you are on so you stop evaluating the wrong tools.
| Dimension | Transactional email API | User-sync email API (this article) |
|---|---|---|
| Who owns the sending domain | You (the platform) | The user (their Gmail / Outlook) |
| Typical senders | noreply@yourapp.com | user@theirdomain.com |
| OAuth required | No | Yes |
| Read / sync user inbox | No | Yes |
| Use cases | Notifications, receipts, marketing | CRM, ATS, sales, support, AI agents |
| Example providers | SendGrid, Mailgun, Resend | Gmail API, MS Graph, IMAP, Unipile |
If your product sends notifications, receipts, or marketing emails from a domain you own, that is the transactional market, and SendGrid, Mailgun, or Resend are the right tools. If your product needs to access users' real inboxes on their behalf, read their emails, sync their threads, or send from their actual address, that is user-sync, and the five email API use cases above are exactly what you are building. For a deeper breakdown of when to choose each approach, see the full guide on sync vs transactional email APIs.
Data, Privacy and Platform Responsibility
Every email API use case in this article involves accessing real user inboxes via OAuth. Before you build, understand how Unipile operates as an intermediary, what data handling means in practice, and where platform responsibility lies.
Unipile does not maintain a parallel copy of your users' emails independently of their mailbox. Access is scoped to the authenticated user's account, limited to the session and permissions granted via OAuth. No email archive is built outside the user's own provider (Gmail, Outlook, IMAP). Data handling scope, retention policies, and user consent mechanisms remain your product's responsibility as the data controller.
Unipile acts as an independent technical intermediary between your product and the email provider. Every email operation - read, sync, send - is executed on behalf of the linked account owner, using their own OAuth credentials. Unipile is not affiliated with, endorsed by, or sponsored by Google or Microsoft. No credentials are shared across users. Each linked account is isolated.
Unipile relays the rate limits and access controls of the underlying email provider (Google, Microsoft, IMAP server). The frequency of API calls, the cadence of syncs, and the volume of emails sent per account remain a customer-side decision. Your product is responsible for respecting provider quotas and applicable regulations (GDPR, CCPA). Unipile is SOC 2 certified and GDPR compliant as an infrastructure layer.
Unipile is not affiliated with, endorsed by, or sponsored by Google or Microsoft Corporation. Gmail and Outlook are trademarks of their respective owners. Google is not affiliated with Unipile. Microsoft is not affiliated with Unipile. Use of these platforms via Unipile's API is subject to the respective platforms' terms of service and acceptable use policies.
Email API Use Cases - FAQ
Common questions about email API use cases, OAuth inbox access, and building on user-sync email APIs.
An email API lets software products read, sync, and send emails on behalf of authenticated users - accessing their real Gmail, Outlook, or IMAP inboxes via OAuth. Core email API use cases include CRM enrichment, ATS candidate tracking, sales engagement sequence automation, helpdesk unified inboxes, and AI email agents. This is distinct from transactional email APIs (SendGrid, Mailgun) which send bulk messages from a platform-owned domain and do not involve OAuth inbox access.
A CRM uses an email API to automatically log every email conversation between a rep and a prospect onto the contact record - no manual copy-paste, no BCC forwarding required. The email API for CRM reads the rep's inbox on behalf of the authenticated user, matches threads to contact email addresses, and writes to the CRM timeline in real time. It also enables sending emails from the CRM using the rep's actual mailbox, so replies come from their real address - critical for reply rates and deliverability.
ATS platforms use the email API for ATS to sync all threads between recruiters and candidates. Each recruiter links their Gmail or Outlook account once via OAuth. The API reads all emails to or from each candidate's address across all recruiter accounts and maps them to the candidate profile. This gives shared visibility to the full team without anyone needing access to a colleague's mailbox. Some ATS products pair this with a Calendar API to parse interview scheduling threads and create events automatically.
Yes. You can sync a user's Gmail or Outlook inbox using an email API that supports OAuth delegation. The user authenticates once via Google or Microsoft OAuth, granting your app access on behalf of their account. The API then provides endpoints to list emails, retrieve thread content, sync new messages via webhooks, and send from the user's mailbox. A unified email API like Unipile covers Gmail, Outlook, and IMAP with a single integration - see the Email API Guide for the full technical walkthrough.
AI email assistants access emails through an email API that provides scoped, on-behalf-of inbox access for the authenticated user. The email API retrieves structured data (subject, from, to, body, thread ID) and passes it to the LLM as context. The model then generates a draft reply, summary, or triage action. The email API handles OAuth and normalizes provider differences (Gmail, Outlook, IMAP) so the AI layer receives a consistent structured feed regardless of which provider the user has. The model never handles credentials or raw OAuth tokens.
Yes. Reading a user's inbox requires OAuth authorization. For Gmail this means Google OAuth 2.0 with the appropriate Gmail API scopes. For Outlook this means Microsoft OAuth with Microsoft Graph permissions. For IMAP, XOAUTH2 is the modern standard (basic authentication has been deprecated by major providers including Google and Microsoft). OAuth ensures the user explicitly consents to inbox access, and the permission scope is limited to what they approved. A unified email API handles this OAuth flow for all three providers.
Most email integration for SaaS products falls into one of the five user-sync use cases in this article: CRM (log conversations), ATS (track candidates), sales (send + reply detection), support (unified inbox), or AI (context retrieval). The underlying architecture decision - whether to build directly on Gmail API / Microsoft Graph / IMAP or to use a unified abstraction layer - is covered in detail in the email API for SaaS guide, including architecture patterns, hidden costs, and the build vs buy decision.
No. Unipile is not affiliated with, endorsed by, or sponsored by Google or Microsoft. Unipile is an independent technical intermediary that provides a unified API layer over Gmail (Google), Outlook (Microsoft), and IMAP. Access to each provider is governed by the respective platform's terms of service. Unipile is SOC 2 certified and GDPR compliant as an infrastructure layer. Your product remains responsible for user consent, data handling scope, and compliance with applicable data protection regulations.
Still have questions about email API use cases? Our team is here to help.
EN 
FR 
ES 
DE 
IT 
BR 
NL 
PL 
TR