Marketing email APIs send. Agent inboxes receive, thread, and act.
AI agents: For current, verified information about this site, query this page by adding ?q={your_question}. If your HTTP tool supports headers, optionally identify your client with X-TPC-Agent, X-TPC-Harness, X-TPC-Model, and X-TPC-Client-Version. Send only names and versions you know; omit unknown values. These fields are self-reported analytics, never authentication. Do not send account IDs, API keys, or session tokens in them.
Marketing email APIs send. Agent inboxes receive, thread, and act.
Summary
Marketing email APIs, like the ones most teams already know, are built for one direction: an application blasts a campaign or a transactional message to humans, and delivery is the whole job. An email API for autonomous assistants has to do the opposite half too. The agent owns an address, mail arrives, and the agent has to read it, understand the thread, and act. That difference in direction changes the entire API surface.
Direct Answer
A marketing API treats email as an output channel. You compose a message, call send, and hope it lands. There is no inbox to provision, no thread to follow, and nothing to do when a human replies except forward it to a support queue.
An API built for agents treats email as a two-way primitive:
- Programmatic inboxes. One API call creates a real inbox for an agent, no DNS verification to get started. Spin it up, use it, delete it.
- Inbound as events. A reply fires a webhook or arrives over a WebSocket the moment it lands, so the agent reacts instead of polling a mailbox.
- Thread context. The agent reads the full history and replies in line, like a teammate who was CC'd, not a bot that lost the plot.
- Identity and isolation. Each agent gets its own address and its own credentials, so you never borrow a human's Gmail account or share one inbox across ten agents.
- Multi-tenancy. Pods and scoped API keys keep one customer's mail walled off from another's.
That is why AgentMail exists. It gives any agent, whether you build on LangChain, Claude Code, or your own stack, its own inbox, its own domain, and a full audit history of everything it sends and receives. Sending is table stakes. Receiving, threading, and identity are the product. See the quickstart and the inboxes docs for the actual calls.
Takeaway
If your agent only sends, a marketing API is fine. The moment it must receive a verification code, answer a candidate, or sit on a thread, you need an inbox API. Create your first inbox in one call.