Send Email API: Send from User Gmail, Outlook & IMAP Accounts
Most email APIs send from a shared domain you own. Unipile's send email API is different: it sends from your users' own Gmail, Outlook, and IMAP accounts, with full OAuth2, no credential storage, and a single unified endpoint for every provider. When your SaaS needs to send email programmatically on behalf of real people, this is the integration that makes it work.
A Send Email API That Acts on Behalf of Your Users
Most "send email API" searches lead to transactional providers. That is not this. Unipile is a user-account email API: it connects to your users' real Gmail or Outlook accounts and sends on their behalf, with their identity and their deliverability.
Why Developers Build on a User-Account Email API
When your product needs to send email programmatically from real people (not a noreply@ address), these are the scenarios that drive adoption.
Send follow-up emails from each sales rep's own Gmail or Outlook account. Higher reply rates, authentic sender identity, no domain warming required. Prospects see a real name, not a generic alias.
Let support agents reply directly from their own mailbox. Customers see a real person's name and email address, not a support@ alias. Builds trust, increases resolution speed.
Reach candidates with personalized emails from the recruiter's actual account. No cold domain, no spam filter risk, no warmup period. The email arrives in the inbox like a personal message, because it is one.
Send Email from Gmail, Outlook, and IMAP: One API
Unipile's send email API abstracts the provider layer completely. Whether your user's account is Gmail, Outlook, Microsoft 365, Exchange Online, or any IMAP-compatible mailbox, the API call is identical. You write the integration once and every provider just works.
gmail.send: minimal permission footprint
Mail.Send: delegated or app-level
How to Send Email via API: Step by Step Integration
From account linking to sending your first email programmatically, here is the complete flow. This guide covers Gmail and Outlook; the steps for IMAP are identical, only the account type differs.
Sign up at the Unipile dashboard. Every workspace gets an API key. All requests are authenticated with the X-API-KEY header. No OAuth setup on your side: Unipile handles the provider authentication for you.
Generate a hosted auth link via the API. The user clicks it and goes through the standard OAuth2 consent screen for their provider. Unipile stores the tokens securely and returns an account_id. You never touch credentials.
"type":"MICROSOFT". For IMAP, use "type":"IMAP". The same hosted flow handles all three providers.After the user completes OAuth2, Unipile fires a webhook to your endpoint with the account_id. Store it in your database: it is the key you will use in every send email API call for that user.
POST to /api/v1/emails with the account_id. The email goes out from the user's actual Gmail or Outlook inbox, same as if they hit send themselves. The endpoint is identical regardless of whether the linked account is Gmail, Outlook, or IMAP.
Hi John,
Just wanted to follow up...
" }'Hi John,
Just wanted to follow up...
' }) }); const data = await res.json();Hi John,
Just wanted to follow up...
' } ) print(res.json())"cc", "bcc", "reply_to", and "attachments" to the same payload.Ready to send emails from Gmail, Outlook, and IMAP?
Your API key is waiting. Start building in under 10 minutes.
One Unified Endpoint to Send Email Across All Providers
The biggest friction in multi-provider integrations is maintaining separate code paths for each email service. Unipile eliminates that. Whether the linked account is Gmail, Outlook, or IMAP, you always call the same endpoint with the same payload. The abstraction layer handles provider-specific protocols, token refreshes, and rate limit differences behind the scenes.
Hi John...
" } // Works for Gmail, Outlook, and IMAP // account_id tells Unipile which account to useNo separate code paths for Gmail vs Outlook. One integration covers all three providers today and any future additions Unipile adds.
OAuth2 access tokens expire. Unipile refreshes them transparently. Your code never handles token lifecycle; just call the API and send.
Each user links their own account. You manage an account_id per user; Unipile handles the rest. No per-provider SDK juggling.
The API returns the same JSON structure regardless of provider. Parse one schema, build one error handler, ship faster.
Need to send emails on behalf of your users at scale? Read the full guide on how to send emails on behalf of your users, including the compliance and consent model Unipile uses to keep everything auditable.
All Send Email API Endpoints, Organized
Every endpoint available for connecting accounts, sending and replying, managing your mailbox, and listening to events across Gmail, Outlook, and IMAP with a single integration.
Send & Reply
4 endpoints available
Account Setup
3 endpoints available
Manage Emails
5 endpoints available
Webhooks
2 events available
Covers authentication flows, webhook setup, reading and sending emails, attachments, and full provider comparison, everything you need to build a production-ready send email API integration.
Authentication and Security for Your Send Email API Integration
Handling user email credentials is one of the highest-risk parts of any SaaS integration. Unipile's architecture is designed so you never store or transmit OAuth2 tokens directly; the risk surface stays minimal and compliance stays manageable.
Unipile generates the OAuth2 consent URL, collects the authorization code, and stores the access and refresh tokens in its own encrypted vault. Your backend only ever sees an account_id. No raw token, no password, no credential drift.
Gmail OAuth2 tokens expire after 1 hour. Microsoft tokens expire after 1 hour (access) or 90 days (refresh). Unipile refreshes them automatically before expiry. Your send email API calls never fail due to a stale token.
For a send-only integration, Unipile requests only the scopes required: gmail.send for Gmail and Mail.Send for Outlook. This follows the principle of least privilege and reduces the attack surface for your users' data.
Every webhook Unipile sends to your endpoint includes a signature header you can verify against your webhook secret. This ensures event payloads cannot be forged by third parties attempting to trigger actions in your system.
Unipile's infrastructure is SOC 2 Type II certified. Audited controls cover access management, encryption at rest and in transit, incident response, and availability. This makes it straightforward to pass vendor security reviews when your SaaS customers ask how you handle their email credentials.
Learn about the secure email APIUnipile is CASA Tier 2 assessed, the security standard required by Google for applications accessing sensitive Gmail API scopes. The assessment is conducted by an authorized lab and covers data handling, access controls, and secure development practices. Required to maintain production access to Gmail sending scopes.
Full Email API Feature Coverage Across All Providers
One integration gives you access to every major email operation across Gmail, Outlook, and IMAP providers. The same endpoint, the same payload structure, the same response format regardless of which account your user has connected.
| Feature | Gmail | Outlook / M365 | IMAP / SMTP |
|---|---|---|---|
| Sending | |||
| Send email from user account | ✓ | ✓ | ✓ |
| Send with attachments | ✓ | ✓ | ✓ |
| Reply in existing thread | ✓ | ✓ | ✓ |
| CC and BCC recipients | ✓ | ✓ | ✓ |
| HTML body content | ✓ | ✓ | ✓ |
| Inline images (CID embedding) | ✓ | ✓ | ✓ |
| Daily send limit (approx.) | ~500 / day | ~10,000 / day | Server-dependent |
| Reading & Sync | |||
| List and read emails | ✓ | ✓ | ✓ |
| Thread / conversation view | ✓ | ✓ | ✓ |
| Real-time webhooks (new email, read, sent) | ✓ | ✓ | ✓ |
| Incremental delta sync | ✓ | ✓ | ✓ |
| Label and folder management | ✓Labels | ✓Folders | ✓Folders |
| Auth & Security | |||
| OAuth2 (no password storage) | ✓ | ✓ | App password |
| Automatic token refresh | ✓ | ✓ | ✓ |
| SOC 2 Type II / CASA Tier 2 | ✓ | ✓ | ✓ |
Common Mistakes When Building a Send Email API Integration
Most issues developers encounter when integrating a user-account send email API fall into a small set of categories. Here are the ones worth knowing before you start building.
Gmail personal accounts are limited to approximately 500 emails per day. Outlook accounts have higher limits but can still throttle under burst conditions. Exceeding these limits results in 429 errors or temporary account suspension by the provider.
Users can revoke access at any time from their Google or Microsoft account settings. When this happens, Unipile will return an error on the next API call for that account. If your application does not handle this gracefully, it results in silent email delivery failures.
account.disconnected webhook event and prompt the user to re-link their account.Even with a valid OAuth2 token, sending emails from a user's account without their knowledge violates Google and Microsoft's usage policies and most jurisdictions' spam laws. The OAuth2 consent screen must clearly explain what your application will do.
If you store access tokens yourself and they are exposed in a data breach, an attacker has full access to all linked email accounts. This is a critical security and compliance risk, especially under GDPR.
account_id; Unipile holds the tokens in its SOC 2 certified vault. Your database never touches a raw OAuth2 token.SMTP requires direct server access, credential management, TLS configuration, and bounce handling. A REST send email API abstracts all of that. Combining both approaches in the same codebase adds complexity without benefit.
Frequently Asked Questions
Everything you need to know about the send email API.
account_id via webhook. You then POST to /api/v1/emails with that account_id and your message payload. The email sends from their actual Gmail address. No Gmail API key setup required on your side.Mail.Send delegated permission. Unipile handles token refresh automatically.https://www.googleapis.com/auth/gmail.send. This allows sending emails but does not grant access to read, modify, or delete messages. When using Unipile, you do not configure this scope yourself; the hosted auth flow handles it. For a pure send email API use case, gmail.send is sufficient.POST /api/v1/emails endpoint handles Gmail, Outlook, and IMAP accounts. The provider is determined by the account_id in the payload; you do not need to specify it. Write your sending logic once and it works regardless of which email provider your user has linked. See the detailed breakdown of the 6 main email API providers.Still have questions? Our team is here to help.