LinkedIn
Instagram
WhatsApp
Telegram
Google Calendar
Join Slack CommunityEmail API for Developers:
Build with Gmail, Outlook & IMAP
A practical reference for developers building email integrations: compare Gmail API, Microsoft Graph, and IMAP, then see how a unified email API for developers cuts weeks of boilerplate into a single REST call.
What is an email API for developers?
Before comparing providers and writing code, here is the precise definition that search engines and your teammates both need.
An email API for developers is a programmatic interface that lets your application authenticate as a user, then read, send, or manage that user's emails directly inside Gmail, Outlook, or any IMAP mailbox - without ever handling their password. The API authenticates via OAuth 2.0 (or IMAP credentials), returns structured JSON responses, and fires webhooks when new mail arrives. It is categorically different from a transactional email API (SendGrid, Mailgun), which sends marketing or notification mail on your brand's behalf - an email API for developers acts on behalf of your user, inside their existing mailbox.
In practice: a SaaS helpdesk uses an email API to pull support tickets directly from a customer's Gmail inbox. A CRM uses it to sync every email thread a sales rep exchanges with a prospect. An AI agent uses it to read, classify, and draft replies inside a user's Outlook account. These are sync-side, OAuth user-side integrations - not mass-sending pipelines.
Why developers need an email API integration
These are the four product categories where an email API for developers delivers direct business value - reading and acting on real user emails, not sending bulk blasts.
CRMs, helpdesks, and project management tools need live access to a user's mailbox. Your app authenticates once via OAuth, then reads, threads, and surfaces emails directly in your UI - no copy-paste, no forward rules. The email API integration runs in the background, keeping your data fresh.
LLM-powered agents need to read and classify real emails to draft replies, extract entities, trigger workflows, or route tickets. An email API for developers gives your AI agent structured JSON access to the inbox - subject, body, attachments, headers - without building a custom mail client.
Pull support emails directly from customer mailboxes or shared inboxes, tag them by topic, assign agents, and post replies - all programmatically. The email API integration replaces brittle SMTP polling with a proper REST interface and real-time webhooks.
Log every email a sales rep sends or receives against the right contact or deal. Track open/reply status at the thread level. Keep your CRM in sync with real conversation history without asking reps to BCC a magic address. Pure email api integration - user-side, OAuth-based, on behalf of each individual rep.
This is NOT for transactional email. If your use case is sending password resets, order confirmations, or newsletters from your own domain - that is the transactional market (SendGrid, Mailgun, Resend). Unipile's email API for developers addresses the sync/read/write-on-behalf-of-user market: different infrastructure, different compliance requirements, different pricing model.
Gmail API, Microsoft Graph, and IMAP compared
Every email API integration starts with one of three native providers. Here is what each one offers and where each one creates friction for developers.
| Feature | Gmail API | Microsoft Graph | IMAP | Unipile (unified) |
|---|---|---|---|---|
| Auth method | OAuth 2.0 | OAuth 2.0 | Password / XOAUTH2 | OAuth 2.0 (all) |
| Real-time webhooks | Pub/Sub (GCP needed) | Graph subscriptions | No (IDLE polling) | Unified webhook |
| Response format | Gmail JSON (non-standard) | Graph JSON (OData) | RFC 2822 raw MIME | Unified JSON schema |
| Token refresh | Manual (google-auth-library) | Manual (MSAL) | N/A | Managed by Unipile |
| Rate limits | 250 QU/user/s | 10k req/10 min | Varies by server | Abstracted + retry |
| Send email | Yes | Yes | SMTP only | Yes (all providers) |
| Attachments | Requires extra call | Max 4MB inline | Full MIME | Unified attachment API |
| Setup time (estimate) | 1-2 weeks | 1-2 weeks | 3-5 days | Hours |
Native email API vs unified email API: real code comparison
Seeing both approaches side-by-side - in actual code - makes the tradeoff concrete. Select a language below to compare reading emails natively versus via the Unipile unified email API.
// 1. Install & configure OAuth client
const {google} = require('googleapis');
const auth = new google.auth.OAuth2(
CLIENT_ID, CLIENT_SECRET, REDIRECT_URI
);
// 2. Exchange auth code for tokens
const {tokens} = await auth.getToken(code);
auth.setCredentials(tokens);
// 3. Store & refresh tokens manually
// 4. Call Gmail API
const gmail = google.gmail({
version: 'v1', auth
});
const res = await
gmail.users.messages.list({
userId: 'me', maxResults: 10
});
// 5. Fetch full message per ID
const msg = await
gmail.users.messages.get({
userId: 'me',
id: res.data.messages[0].id,
format: 'full'
});
// 6. Parse base64url-encoded payload yourself// 1. One SDK, all providers
const unipile =
require('@unipile/node-sdk');
const client =
new unipile.UnipileClient(
API_URL, ACCESS_TOKEN
);
// 2. Tokens managed by Unipile
// No manual OAuth flow needed
// 3. List emails
const emails = await
client.email.listAll({
account_id: ACCOUNT_ID,
limit: 10
});
// 4. Body already decoded
// Unified JSON - same schema
// for Gmail, Outlook, IMAP
console.log(emails.items);import msal, requests
# 1. MSAL confidential client
app = msal.ConfidentialClientApplication(
CLIENT_ID,
authority=AUTHORITY,
client_credential=CLIENT_SECRET
)
# 2. Acquire token on behalf of user
result = app.acquire_token_by_auth_code_flow(
flow, auth_response
)
token = result['access_token']
# 3. Handle token refresh, store securely
# 4. Call Graph API
headers = {'Authorization': f'Bearer {token}'}
r = requests.get(
'https://graph.microsoft.com/v1.0/me/messages',
headers=headers
)
# 5. Parse OData envelope responseimport requests
# Token managed by Unipile
# No MSAL, no OAuth setup
headers = {
'X-API-KEY': ACCESS_TOKEN,
'Accept': 'application/json'
}
# Works for Gmail AND Outlook
# Same endpoint, same schema
r = requests.get(
'https://api7.unipile.com:13091'
'/api/v1/emails',
headers=headers,
params={
'account_id': ACCOUNT_ID,
'limit': 10
}
)
emails = r.json()
# Already parsed, no OData# IMAP has no REST API
# Must use imaplib or node-imap
# No cURL equivalent
# Example: openssl s_client
# (debug only - not production)
openssl s_client \
-connect imap.gmail.com:993 \
-quiet
# Then send raw IMAP commands:
# A001 LOGIN user@gmail.com pass
# A002 SELECT INBOX
# A003 FETCH 1 RFC822
# A004 LOGOUT
# You receive raw RFC 2822 MIME
# Must parse headers, decode
# base64 parts, handle multipart
# boundaries yourself
# Also: no webhooks, must IDLE poll# REST API - works with any
# email provider via cURL
curl \
-X GET \
-H "X-API-KEY: $TOKEN" \
-H "Accept: application/json" \
"https://api7.unipile.com:13091
/api/v1/emails
?account_id=$ACCOUNT_ID
&limit=10"
# Response: clean JSON
# { "items": [ { "id": "...",
# "subject": "Hello",
# "from": { "name": "Alice",
# "address": "..." },
# "body_plain": "...",
# "date": "2026-05-12T..." } ] }
# Same endpoint for Gmail,
# Outlook, and IMAP accountsOAuth 2.0 essentials for email API integration
Every production email API integration relies on OAuth 2.0 to authenticate as a user without storing their password. Here is what you need to set up for each provider - and how Unipile handles it for you.
gmail.readonly, gmail.send. Sensitive scopes require Google verification for production.google-auth-library or a custom handler.
Mail.Read, Mail.Send, Mail.ReadWrite.SDKs and tooling for email API integration
Whether you are building natively or using a unified layer, the right SDK reduces boilerplate. Here is the current landscape for each provider and for Unipile.
Official SDK for the Unipile unified email API. Covers email read, send, account management, and webhooks for Gmail, Outlook, and IMAP - in one package. TypeScript definitions included.
@azure/msal-node separate). Well-maintained. OData response format requires extra parsing for simple use cases.Developer-friendly pricing: start free, scale transparently
"Free" native email APIs aren't really free. Gmail API and Microsoft Graph cost zero dollars per API call, but each one demands weeks of engineering: OAuth verification cycles, token refresh logic, webhook infrastructure, retry handlers, error mapping. A mid-size team typically burns 3 to 6 weeks before shipping a single feature. Unipile's unified email API for developers replaces that work with a 7-day free trial, no credit card required.
Bottom line: the API calls are free, the engineering is not. Building production-grade email integration on top of native APIs (auth flows, token refresh, error handling, webhook infrastructure, multi-provider abstraction) commonly costs 3 to 8 weeks of senior dev time per provider, plus ongoing maintenance every time Google or Microsoft ships a breaking change. Unipile prices per linked account per month with transparent tiers. See the Free Email API guide for the full breakdown.
Security and compliance for email API integrations
When your application handles user emails, compliance is not optional. Unipile is built for the two frameworks that matter for developer-facing products handling European and enterprise data.
Unipile is SOC 2 Type II certified. The audit covers the Security, Availability, and Confidentiality trust service criteria. This means independent auditors have verified Unipile's controls over a sustained period - not just at a single point in time. Required by most enterprise buyers and SaaS security questionnaires.
Unipile processes email data as a data processor under GDPR Article 28. Data processing agreements (DPAs) are available for all paid plans. User email data is processed only for the duration of the authenticated session and within the scope granted by the user's OAuth consent. No parallel storage, no data sold to third parties.
Common pitfalls in email API integration (and how to fix them)
Every developer building their first email API integration hits the same four walls. Here they are - and how to handle each one correctly.
Gmail's 250 quota units per user per second sounds generous until you realize listing 10 messages costs 5-10 units each and fetching full bodies adds per-byte quota. Microsoft Graph caps at 10,000 requests per 10 minutes per app per tenant. Hitting the limit returns 429 - Too Many Requests. Without retry logic your sync loop crashes silently.
Google access tokens expire after 3,600 seconds. Microsoft tokens after 60-90 minutes. If your refresh token is revoked (user changes password, revokes app access, or the token has not been used in 6 months for Google), your entire sync silently stops. No error is surfaced unless you monitor the refresh call response.
Microsoft Graph subscriptions expire after a maximum of 4,230 minutes (~3 days for mail). Forgetting to renew them means no more push notifications - your app falls back to polling or misses events entirely. Gmail Pub/Sub subscriptions are more persistent but require a GCP subscription to remain valid and the topic to exist.
Email APIs are eventually consistent. If your sync process crashes mid-run, you may duplicate emails, skip a page of results, or miss deletes. Gmail uses historyId for incremental sync; Microsoft Graph uses deltaToken. Both require careful cursor management across restarts. IMAP has no native sync state - you must maintain your own UID tracking.
Email API for developers - frequently asked questions
Answers to the questions developers ask most often when building their first email API integration across Gmail, Outlook, and IMAP.
npm install @unipile/node-sdk. Then create a client with your API URL and access token, and call client.email.listAll() to read emails or client.email.send() to send - across Gmail, Outlook, and IMAP with a single code path. For native Gmail, use the googleapis npm package. For Microsoft Graph, use @microsoft/microsoft-graph-client.
EN 
FR 
ES 
DE 
IT 
BR 
NL 
PL 
TR