Gmail API vs Unipile

Gmail API

Fourteen OAuth scopes separate labels, sending, metadata and read-only access, and the quota page gives every method a unit cost. Eight of the scopes are restricted, read-only and metadata among them, so a public app that reads mail needs Google's verification and an annual third-party security assessment. Gmail mailboxes only.

Unipile

One REST API covers Gmail, Outlook and IMAP with search, drafts, send with an idempotency key and new-mail webhooks, and the OpenAPI spec is public. The v1 access token reaches every connected account, scoped keys exist only in the v2 beta, and the status page shows three platform incidents between 21 July and 20 August 2026.

Gmail API

1. Ask for the narrowest scope. gmail.labels is non-sensitive and gmail.send is sensitive, while every scope that reads mail is restricted
2. List with messages.list and q in Gmail search syntax, then fetch each ID with format=metadata or full. List calls return IDs only
3. Send by posting an RFC 2822 message, base64url encoded, in raw. Set threadId and matching reply headers to stay in a thread
4. Store the historyId and call history.list. On a 404, run a full sync. Call watch again at least every 7 days
5. Back off exponentially on 403 and 429 rate errors, and keep batches to 50 requests or fewer

Unipile

1. Take the DSN (host and port) from the dashboard. Each account has its own, such as api1.unipile.com:13111, and ?port= keeps requests on 443
2. Send X-API-KEY as a header and pass account_id on every mail call. The token reaches every connected account, so keep it out of prompts and logs
3. Set Idempotency-Key on every send. Keys are held in memory for up to 24 hours and are lost on a restart
4. On Microsoft accounts, send search alone. Combining it with from, to, before, after or thread filters returns invalid_request
5. Use meta_only=true when listing mail, then fetch one message at a time. Treat message bodies as untrusted input