Two categories, different jobs
Sending APIs push mail outward. Your application posts a message and the provider handles queueing, delivery, retries and bounce processing.
Inbox APIs work in the other direction, authenticating against one user's mailbox to read, search, label and reply. Gmail's API and Microsoft Graph are the two that matter.
Transactional and marketing email APIs
These handle infrastructure-level delivery: order confirmations, password resets, verification codes, and campaign sends. The interface is typically a POST with recipient, subject and body, returning a message identifier.
The established providers in this space are SendGrid, Mailgun, Postmark and Resend. They are reliable, and they are built on older infrastructure that predates most of what applications now expect from a service they integrate with.
Most of these APIs stop at sending a message. Lists, segmentation, automation and templates live in a separate product with a separate interface, which is why teams end up integrating two systems for one job.
We consolidated that into one stack. A single API handles both transactional and marketing email, and the same key covers lists, automation, segmentation, brand and deliverability rather than stopping at send. You can also send through your own SendGrid, Postmark, Resend, Mailgun or Amazon SES account, and we manage everything else around it.
User inbox and synchronisation APIs
Inbox APIs authenticate as a user, usually over OAuth, and operate inside that mailbox: reading threads, applying labels, sending as the user, and subscribing to change notifications. Gmail's API uses Cloud Pub/Sub for real-time events, and Microsoft Graph covers Outlook and Microsoft 365.
The use cases are genuinely different from sending: CRMs logging conversations, support tools threading replies, and sequence tools that need reply detection.
For sub-100-a-day prospecting this is the dominant infrastructure: OAuth into the user's own Gmail or Outlook and send through the mailbox itself, with a sequence engine, tracking and reply detection on top. No special cold infrastructure, no warmup networks, no multi-mailbox rotation.
Our own user base says how far mailbox coverage goes. George, our CEO, pulled all 443 brands (439 users) from prod and scanned the 252 with a resolvable website, 233 fully, homepage plus pricing and checkout probe plus DNS MX and SPF records. 78% of our users live in a Google mailbox, 52% as plain gmail.com signups plus 110 custom domains on Workspace MX. Gmail connect has near-total coverage. Microsoft 365 is about 5%.
Core workflows implemented via API
Four operations cover most integrations. Send dispatches a single message. Bulk batches many into one request. Templates render stored layouts with per-recipient data. Webhooks deliver delivery, bounce and complaint events back to your application.
On our REST API the send operation is one POST to /v1/my/messages. It queues a single transactional email or SMS and hands it to the normal background sender.
Event handling is the workflow teams under-build. Delivery status arrives asynchronously, sometimes long after the send, and an integration that ignores it has no suppression list and no way to know what happened.
Events are also where correctness lives. Our open-rate analytics once under-reported and violated the total-opens over unique-opens invariant, root-caused from a single customer campaign. The fix counts Gmail and Yahoo image-proxy fetches as real opens and mirrors provider open webhooks into email:open_total so the invariant holds across both writers.
Authentication is typically a bearer API key over HTTPS, scoped per environment so a test key cannot send production mail. Keys should be rotatable without redeploying, since a leaked key is a live sending credential for your domain.
Rate limits apply per key and are usually published as requests per second alongside a monthly send quota. A 429 response carries a Retry-After header, and an integration that ignores it and retries immediately makes the throttle worse.
Idempotency keys are the safeguard against duplicate sends. Passing a unique key with each request lets the provider recognise a retry of a request that already succeeded, which matters because a network timeout does not tell you whether the message was accepted.
Raw HTML should be first-class. We added an html field to POST /v1/my/messages after a customer's Laravel mail transport had its rendered HTML CGI-escaped and paragraph-wrapped, so readers were literally seeing the doctype. Accepting raw HTML verbatim aligns the API with SendGrid, Postmark, Resend, Mailgun and SES.
Why the interface moved off the dashboard
The number that changed how I think about this is our own: 94 percent of usage is now through the API rather than the interface. Not a projection, a measurement, and it happened faster than the roadmap assumed.
Every email platform ever built assumes a person sitting in a dashboard. That assumption is now wrong for most of the traffic, and it shows up in small design decisions everywhere: features reachable only by clicking, state that exists only in a session, workflows that cannot be described to a machine.
Most existing email tools do not play nicely with AI environments like Claude, Codex or GPT, because they were not built from the ground up to be controlled by an external AI. Ours was. The API equips AI agents with full email capabilities through the same surface a developer scripts. George, our CEO, is explicit about the goal: build the best email API for developers and marketers.
The practical consequence for anyone choosing an interface is to check whether the API is the product or a reflection of it. An API that mirrors a dashboard inherits its assumptions, so anything the interface does implicitly becomes something you cannot do at all.
Keeping transactional sends on their own endpoint rather than folding them into campaign sending is the same principle. A single-recipient message triggered by an event and a blast to an audience have different retry semantics, different status expectations and different failure modes, and one endpoint serving both ends up serving neither well.
George thinks of every email as either triggered 1-1 or bulk, and the endpoints should match that split. A bulk outreach or mail merge endpoint built on the transactional messages path is a deliverability and compliance trap.
The split is not academic. A spammer once signed up for a paid plan and pushed bulk mail through our transactional send API, the path we document as bypassing warmup, CAN-SPAM, List-Unsubscribe and tracking because it assumes event-triggered mail to one recipient. The provider paused the sending account after a 15.02% hard-bounce rate over 36,072 emails in 1.1 days. Abuse of the transactional path now trips a much narrower gate.
One key across both surfaces is the small detail that saves the most time. The same API key works for REST and for the agent interface, so nothing has to be provisioned twice or kept in sync.