LinkedIn
Instagram
WhatsApp
Telegram
Google Calendar
Join Slack CommunityBuilding a multi-provider email API integration that works across Gmail, Outlook, and IMAP is one of the most time-consuming challenges for development teams. Each provider ships its own OAuth flow, rate limits, and data model. A unified email API abstracts all of that into a single REST interface - so you write one integration and get coverage for every major inbox your users rely on.
What you will learn
Complete Email API Guide
Learn how Gmail, Outlook, and IMAP work together under one unified REST API.
Why developers need a multi-provider Email API
Most SaaS products eventually need to read or send emails on behalf of their users. The problem is not the concept - it is the execution. Gmail uses the Gmail API with Google OAuth 2.0. Outlook uses Microsoft Graph with its own token lifecycle. IMAP-based providers each behave slightly differently. Building and maintaining three separate integrations drains engineering cycles that should go toward your core product. If you are dealing with IMAP accounts specifically, the IMAP API guide covers the additional complexity involved. A unified email API solves this by collapsing all provider-specific complexity behind a single interface - that is the core promise of a multi-provider email API approach.
The 3 email providers covered
One unified API normalises Gmail, Outlook, and IMAP into an identical interface. Your code never changes when a user connects a different provider.
Connect any Gmail or Google Workspace account via Google OAuth 2.0. Send, read, search, and sync threads in real time through the Unipile layer - no direct Gmail API credentials required in your app.
Supports personal Outlook accounts, Microsoft 365, and Exchange Online under a single provider handle. Microsoft OAuth is managed by Unipile - your integration stays stable across tenant configurations.
Any mailbox reachable over IMAP - Yahoo, Fastmail, ProtonMail Bridge, custom corporate servers - becomes instantly accessible through the same API surface used for Gmail and Outlook.
Unipile vs building it yourself
What does it actually cost to DIY a multi-provider email API integration? Here is an honest comparison across the dimensions that matter in production. This is why teams increasingly choose a unified email API like Unipile instead of building each provider integration from scratch.
How the integration works
Connecting your first email account with Unipile takes four steps. The same flow works regardless of whether the user has a Gmail, Outlook, or IMAP account - your application code stays identical throughout. This is the practical power of a unified email API: write once, cover all three providers.
Your backend calls the Unipile API to create a short-lived hosted authentication URL. Redirect the user to that URL - Unipile presents the provider selection screen and handles the full OAuth flow on your behalf.
// POST /api/v1/hosted/accounts/link const res = await fetch('https://api5.unipile.com:13515/api/v1/hosted/accounts/link', { method: 'POST', headers: { 'X-API-KEY': process.env.UNIPILE_API_KEY, 'Content-Type': 'application/json' }, body: JSON.stringify({ type: 'EMAIL', providers_filter: ['GOOGLE', 'MICROSOFT', 'IMAP'], success_redirect_url: 'https://yourapp.com/auth/success' }) }); const { url } = await res.json(); // redirect user to `url`
Once the user completes OAuth, Unipile fires a webhook to your endpoint (or appends the account ID to your redirect URL). Store this account ID - it is your permanent reference to that linked account, provider-agnostic.
{
"event": "account.connected",
"account_id": "acc_01HXYZ...",
"provider": "GOOGLE",
"email": "alice@gmail.com"
}
Use the account ID to list, search, and retrieve emails. This is the unified email API in action: the response schema is identical whether the account is Gmail, Outlook, or IMAP - your parsing logic never branches on provider.
// GET /api/v1/emails?account_id=acc_01HXYZ... const emails = await fetch( `https://api5.unipile.com:13515/api/v1/emails?account_id=${accountId}&limit=20`, { headers: { 'X-API-KEY': process.env.UNIPILE_API_KEY } } ).then(r => r.json()); // Same response shape for Gmail, Outlook, IMAP: // { id, subject, from, to, date, body, attachments }
A single POST endpoint sends email regardless of the provider behind the account - this is the full power of a multi-provider email API. Pass the account ID, recipient, subject, and body - Unipile routes through Gmail API, Microsoft Graph, or SMTP as appropriate. This is the unified email API in its most concrete form: one endpoint, three providers, zero branching in your code.
// POST /api/v1/emails/send await fetch('https://api5.unipile.com:13515/api/v1/emails/send', { method: 'POST', headers: { 'X-API-KEY': process.env.UNIPILE_API_KEY, 'Content-Type': 'application/json' }, body: JSON.stringify({ account_id: 'acc_01HXYZ...', to: [{ email: 'bob@example.com' }], subject: 'Hello from Unipile', body: 'Works across Gmail, Outlook and IMAP.
' }) });
How provider abstraction works
The unified email API sits between your application and the three underlying provider protocols - translating divergent OAuth flows, data schemas, and rate-limit models into a single consistent interface.
Gmail uses Google OAuth 2.0 with a specific token refresh cycle and returns emails in a thread-centric model with labels. Outlook uses Microsoft Graph with a different OAuth tenant model and returns emails as individual message objects with folders. IMAP servers each have their own connection parameters, authentication methods, and capability sets.
Unipile's unified email API normalises all three into a single REST interface. Your code calls /api/v1/emails and receives identically shaped response objects - regardless of whether the underlying account is a Gmail, Outlook, or IMAP account. The same applies to sending, attachment handling, webhook events, and account lifecycle management.
This is the core engineering benefit of the multi-provider email API model: the complexity is absorbed at the infrastructure layer, not in your application code. When Google changes its OAuth scope requirements or Microsoft updates Graph API pagination, Unipile handles the upstream change - your integration stays intact.
Security and compliance
When your application handles email on behalf of users, security is not optional. Here is how the unified email API layer manages credentials, data, and compliance obligations.
Unipile stores and refreshes OAuth tokens on your behalf. Your application never handles raw credentials - you work only with opaque account IDs. Token rotation, expiry detection, and re-authentication flows are managed entirely at the infrastructure layer.
All data in transit uses TLS 1.3. Stored credentials are encrypted at rest with AES-256. Email content fetched through the unified email API is processed in memory and not persisted beyond what your integration explicitly requests.
Unipile is SOC 2 Type II certified (October 2025). Independent auditors have verified the security, availability, and confidentiality of the platform. Audit reports are available on request for enterprise customers evaluating the multi-provider email API for production use.
Data processing agreements are available for all plans. EU data residency option is offered for customers with data localisation requirements. Right to erasure is supported via API: deleting a linked account removes all associated tokens and cached data.
Google Cloud Application Security Assessment. Validates security controls for applications accessing Google user data, including Gmail OAuth scopes. Apps built on Unipile inherit this certification.
Uptime and incident history are publicly available at status.unipile.com. All API changes follow a versioning policy with deprecation notices. No silent breaking changes: your integration is protected by a stable, documented contract.
Handling edge cases across providers
Every production email integration encounters provider-specific edge cases. Here is how a DIY approach compares to using a unified email API when things get complicated.
| Scenario | DIY approach | Unipile approach |
|---|---|---|
| Gmail rate limit 250 quota units/day free tier |
Manual quota tracking per account; requests fail silently if not monitored | Handled automatically Queuing built-in, no failed requests surfaced to your app |
| OAuth token expiry | Implement separate refresh logic per provider; token rotation differs between Google and Microsoft | Auto-refresh Zero-downtime token management across all providers |
| IMAP connection drops | Custom reconnect logic per server config; timeouts vary across IMAP implementations | Connection pool managed Persistent connections maintained by Unipile infrastructure |
| Attachment size limits Gmail 25MB, Outlook 150MB, IMAP varies |
Per-provider branching code; must track each provider's limit and update when they change | Unified validation Provider-agnostic size validation; errors returned in consistent schema |
| Provider API changes | Your on-call responsibility; Google and Microsoft push breaking changes with limited notice | Handled by Unipile team Upstream changes absorbed at infrastructure level; your integration stays stable |
Gmail rate limit
250 quota units/day free tierManual quota tracking per account; requests fail silently if not monitored
The pillar guide covers every endpoint of our unified email API in depth - authentication flows, attachment handling, folder sync, search filters, and webhook setup. Everything you need to build a production email integration.
Common use cases
A unified email API is foundational infrastructure for a wide range of product categories. With a multi-provider email API, teams ship features faster and serve more users - regardless of which inbox provider they use. Here are the patterns built most frequently with Unipile.
Automatically pull every customer email into your CRM records. Sales reps see the full conversation history without ever switching tabs or forwarding manually.
Send personalised follow-up sequences from your users' real inboxes - not a shared sending domain - across Gmail and Outlook accounts simultaneously.
Recruiters link their work email and your ATS logs every candidate thread automatically. Reply directly from the ATS UI, routed through their real Outlook or Gmail account.
Build a shared inbox or help-desk that consolidates email from multiple team accounts. Route, assign, and reply - all through a single interface backed by a single API.
Feed email threads into an LLM to generate draft replies, summaries, or action items. Unipile provides the normalised thread data; your AI layer does the reasoning.
Trigger no-code workflows from new emails across any provider. A webhook fires for every incoming message - your automation platform handles the rest without polling.
Every one of these patterns works across Gmail, Outlook, and IMAP with zero provider-specific code in your application. Unipile normalises the differences so your product logic stays clean and your users can connect whichever inbox they prefer. For a complete walkthrough of every endpoint, consult the unified email API guide.
Frequently asked questions
Everything developers ask before integrating a multi-provider email API.
id, subject, from, to, date, and body have the same structure regardless of provider. Your parsing logic, database models, and downstream processing never need to branch on provider type.
Connect Gmail, Outlook, and IMAP accounts through a single API. No OAuth plumbing, no schema mapping, no polling infrastructure to maintain. Start with a 7-day free trial - no credit card required.
EN 
FR 
ES 
DE 
IT 
BR 
NL 
PL 
TR