A mailbox API lets your application handle both directions of email in code: send messages, and also list a mailbox, read what arrives, and reply. Most email APIs stop at send. Real workflows often depend on what comes back.
Half the conversation isn't enough
Think about the workflows that actually need email. A customer replies to a support notification. A partner emails back an approval. A system sends a code and waits for a confirmation. Each of those depends on the inbound half, and a send-only API leaves you stitching a separate inbox integration onto the side. A mailbox API keeps send and receive in one place so the whole exchange is programmable.
What you can do
On the outbound side, send templated and bulk mail through the managed platform. On the inbound side, list the mailbox, read a message, and reply, programmatically or through our MCP server if an AI agent is driving. That's enough to build a loop like "send a request, watch for the reply, parse it, act," with no human refreshing an inbox in the middle.
Where it fits
Automated support triage, reply-driven workflows, agents that need to read and respond to mail, systems that key off an emailed confirmation. Anywhere a reply has to be handled by code rather than a person. If your case needs a specific inbound shape, structured parsing, routing by recipient address, a webhook the moment mail arrives, tell us what you're building and we'll confirm the exact fit before you commit rather than after.
Outbound keeps its deliverability
The replies you send back aren't second-class mail. They go out on the same deliverability-first platform as everything else, so the reputation engine paces them and enforces suppression like any other send. Handling both sides of email in one place means the reply lands as reliably as the original message did.
Common questions
What is a mailbox API?
Most email APIs only send. A mailbox API also lets you receive: list what's landed in a mailbox, read a message, and reply, all programmatically. It closes the loop so your application can treat email as a two-way channel instead of a one-way firehose. Useful anywhere a reply needs to be handled by code rather than a human refreshing an inbox.
What can I do with it here?
You can send (templated and bulk), and on the inbound side list the mailbox, read incoming mail, and reply, through the API and through our MCP server for AI agents. So a workflow like 'send a request, wait for the reply, parse it, act on it' can run end to end in code without a person in the middle.
How is this different from just sending through an email API?
A send-only API is half the conversation. Plenty of real workflows depend on what comes back: a customer replies to a notification, a system emails a confirmation code, an approval comes in by email. Handling those in code needs inbound access. A mailbox API gives you that receive-and-reply half so the whole exchange is programmable.
Do inbound and outbound share the same reputation handling?
Outbound sending runs on the same deliverability-first platform as everything else here, so the reputation engine paces it and enforces suppression. Inbound is about receiving and processing what arrives. Keeping both in one place means the reply you send back to an inbound message is sent with the same reputation care as any other outbound mail.
Is the inbound side generally available?
The receive-and-reply capability is exposed through the platform and the MCP server. If your use case needs a specific inbound-processing shape (parsing structured replies, routing by address, webhook-on-receive), tell us what you're building and we'll confirm exactly what fits before you commit, rather than you discovering the edges in production.
Related
- Email API: the send-focused view of the platform
- Email Automation API: the workflow layer on top
- MCP Email Server: the same capabilities for AI agents
- Email Webhooks: get notified when things happen
- Return-Path: how bounces route back on the inbound side