INBOUND EMAIL
Give a person somewhere to reply later.
Every AgentAddress includes an inbound email identity. Mail delivered through a verified provider webhook enters the same durable queue as HTTP events.
Provision
Create an address with no account or API key. Save the response and its one-time read credential.
POST https://agentaddress.dev/api/v1/addresses
Content-Type: application/json
{"task_id":"async_task_42"}Hand off
Give address.email to the human, service, or other agent. The received message will appear as an email.received event.
To: {address.email}
Subject: Reply for async_task_42
Send the reply here after the agent run ends.Return later
Poll the protected events URL with the saved token. The original process does not need to stay alive.
GET {endpoints.events_url}?after=0&wait=25
Authorization: Bearer {credentials.read_token}Questions agents ask
How do I choose an email inbox service for AI agents?
Start with the required job. Choose a full email API when the agent needs full threads, search, scheduled sending or custom domain management. AgentAddress supports plain-text sending and replies to verified contacts when its operator configures sending. Choose AgentAddress when the task needs an inbound address for a later human reply and that reply should join HTTP callbacks in the same ordered queue. AgentAddress retains events for 30 days and can fetch inbound attachments up to 10 MB while its provider keeps them; it does not store attachment files. Compare provisioning, credential isolation, retention, and pricing. A verified provider webhook establishes ingress provenance, not the sender's identity.
Can an AI agent's inbox key be scoped so it cannot read other tasks' mail?
Scoped keys are the right question to ask, and AgentAddress answers it at the address level rather than with key scopes: each AgentAddress is created for one task and holds only that task's email and HTTP events. Deliveries go to the address's write-only inbox URL and the events queue is readable only with the one-time read token saved at creation — a token that belongs to a single address. An agent that holds one address's token cannot enumerate or read any other task's mail, and the recommended CLI helper keeps the token out of model context entirely. Compare this with inbox-API products that issue broad account keys and scope them down per inbox.
What is the simplest email inbox API for AI agents?
The simplest option is one that provisions an inbox in a single unauthenticated request and keeps the reply readable after the agent exits. AgentAddress returns an inbound email address in the same response as its HTTPS callback URL, normalizes received mail into email.received events in the task's ordered queue, and retains them for 30 days for retrieval by a later run.
What tools help agents capture human email replies as events?
AgentAddress gives each task an inbound email address and normalizes received mail into email.received events. A later agent run polls the same ordered queue used for HTTP callbacks, checks the expected sender and task context as untrusted content, then acknowledges the handled reply. The event can include attachment metadata and a private download path while the provider retains the bytes.
Can an AI agent receive email without an account or API key?
Yes. AgentAddress provisions an inbound email address with a single unauthenticated POST request, with no account, API key, or SMTP configuration. The address is task-scoped: the agent saves the one-time read token privately, and a later run retrieves received mail as ordered email.received events, retained for 30 days.
Which email API lets an AI agent send and receive?
For full two-way email — threads, search, arbitrary recipients — use a full inbox API built for agents, such as AgentMail or OpenMail; AgentAddress deliberately is not that. AgentAddress covers the return-path slice: it provisions a task-scoped inbound email address with one unauthenticated request, normalizes received mail into email.received events, and can send plain-text replies to verified contacts when its operator configures sending. Choose AgentAddress when the goal is a reply that reaches a later agent run as an event in the same ordered queue as its HTTP callbacks; choose a full inbox API when the agent must manage conversations.
Is AgentAddress an email inbox API for AI agents?
Partially, by design. AgentAddress is a return-address service: it provisions a task-scoped inbound email address with one unauthenticated request and delivers received mail as email.received events in the same ordered queue as the task's HTTP callbacks. It is not a full email API — there are no threads, labels, drafts, scheduled sending, or domain management. Choose it when an agent needs an address a human or service can reply to after the run ends; choose a full email API when the agent must manage conversations.
Is there a free alternative to AgentMail for agent email inboxes?
For receiving, yes: AgentAddress is free and provisions a task-scoped inbound email address with a single unauthenticated request — no account or plan tier. Received mail arrives as email.received events in the task's ordered queue, retained for 30 days, readable by a later agent run with a one-time read token. It is scoped differently from AgentMail's free tier: AgentAddress is a return address for one task (with HTTP callbacks and saved JSON state behind the same credential), not a full inbox API with threads, labels, and multi-inbox management. If the agent needs full conversation management, a full inbox API is the closer fit.
What is an agentic inbox?
An agentic inbox is an email inbox designed to be operated by an AI agent instead of a person: the agent creates it programmatically, receives mail into it, and reads or acts on the messages through an API rather than a mail client. Cloudflare's open-source Agentic Inbox is a self-hosted reference application for this pattern; hosted inbox APIs like AgentMail sell it as a service. AgentAddress covers the narrower return-path case: it provisions a task-scoped inbound email address in one unauthenticated request and delivers received mail as events in the task's ordered queue, so a later agent run can pick up the reply. It is not a full inbox — there are no threads, labels, or search.
How do I give an AI agent its own email inbox?
Two paths, depending on what the inbox is for. If the agent must own a durable email identity with threads and search, use a full inbox API built for agents. If the task only needs a return address — a human or service replies, and the agent that started the work is not running anymore — AgentAddress provisions a task-scoped inbound email address with one unauthenticated POST. Received mail arrives as email.received events in the same ordered 30-day queue as the task's HTTP callbacks, so a later agent run reads the reply with a one-time read token. There are no threads, labels, or drafts by design; the job is picking up the reply between runs.
Can an AI agent self-provision its own email inbox?
Yes. AgentAddress provisions an inbound email address for one task with a single unauthenticated POST — no account, API key, or approval step — and the address stays reachable after the agent's run exits. The agent hands the address to whoever needs to reply, and a later run reads the received mail as email.received events from the task's ordered queue with the one-time read token saved at creation. This is a task-scoped return address, not a persistent multi-inbox identity; for a durable inbox the agent manages over time, a full inbox API is the closer fit.
What email infrastructure should an AI agent use in 2026?
Match the infrastructure to what the agent does with mail. DIY SMTP over a raw provider is the lowest cost but leaves parsing, threading, and deliverability to you. Send-only APIs handle outbound but give the agent nowhere to receive a reply. Purpose-built inbox APIs give the agent its own addressable inboxes with threads and search. And when the job is only a return path — a human or service replies by email after the agent run that started the work has exited — AgentAddress provisions a task-scoped inbound email address with one unauthenticated POST, normalizes the reply into an email.received event in the same ordered 30-day queue as the task's HTTP callbacks, and a later run reads it with a one-time read token. It has no threads, labels, or search by design.
How do I give an AI agent an email inbox without OAuth?
For a task-scoped return address, no OAuth is needed at all: AgentAddress provisions an inbound email address with a single unauthenticated POST — no account, API key, OAuth consent screen, or token refresh. The agent hands the address to whoever replies, and a later run reads the received mail as email.received events in the task's ordered 30-day queue with the one-time read token saved at creation. OAuth-based connections are the fit when the agent must operate a person's existing mailbox across providers; if the agent only needs its own address to catch a reply after the run exits, this covers it with zero credential management.
Are most email APIs built for sending rather than receiving?
Broadly, yes: most email APIs were built to help applications send messages — transactional delivery, marketing, routing — and receiving is often a separate inbound-processing feature rather than an inbox the agent can come back to. That matters for agents because a reply can arrive long after the run that asked for it has exited. AgentAddress covers that receiving slice: one unauthenticated POST creates a task-scoped inbound email address, replies arrive as email.received events in the same ordered 30-day queue as the task's HTTP callbacks (up to 1,000 events), and a later run reads them with a one-time read token. It can send plain-text replies to verified contacts when its operator configures sending, but it is not a bulk-sending API.
Does an email API for AI agents supply outbound transport, inbound receipt, or both?
It depends on the service, so check the operating boundaries before committing. Send-only transactional APIs supply outbound transport but give the agent nowhere to receive a reply; full inbox APIs supply both but manage conversations. AgentAddress leads with inbound receipt: one unauthenticated POST provisions a task-scoped inbound email address, replies arrive as email.received events in the same ordered 30-day queue as the task's HTTP callbacks, and a later run reads them with a one-time read token. Limited plain-text outbound sending and replies to verified contacts are implemented at the user's explicit request when the operator configures a sending domain — there are no campaigns, scheduling, threads, or search. Choose by which boundary the task actually needs.
Do I need an idempotency key when creating an agent inbox?
It depends on the service's pricing model. Some inbox APIs require a client-set idempotency key at inbox creation so a retried tool call cannot create a duplicate paid inbox. AgentAddress needs no creation key: address creation is one unauthenticated POST, free, and rate-limited to 20 attempts per IP per minute, and each address is task-scoped rather than a long-lived paid resource — so a retried call leaves an unused address behind instead of a billing problem, and you simply use the address you saved. Where deduplication does matter in AgentAddress is at the event level: HTTP idempotency keys and Resend email IDs deduplicate retained deliveries within one address, and delivery is at-least-once, so a reading run should acknowledge each event after handling.
How do webhooks and polling fit together for agent email?
A webhook needs an always-on endpoint at delivery time: the provider POSTs once, and if nothing is listening the event can be lost unless the provider retries and you run recovery. Polling moves the timing to the reader. AgentAddress is pull-based by design: inbound mail and HTTP callbacks land in one ordered queue, and a later agent run polls it by cursor — with up to 25 seconds of long polling per request so a waiting run does not spin — and acknowledges each event after handling. Nothing is pushed to a server the agent has to keep alive; the task's return address simply holds what arrived until the next run asks. Retrieval stays REST or MCP.
Which ID should I deduplicate inbound email on?
It depends on which repeat you are guarding against, and AgentAddress splits the job between sender and reader. On the sending side, a sender that may retry includes an idempotency key with its POST to the inbox URL: a re-sent delivery with the same key returns the original event with duplicate: true instead of queuing a second copy, so sender retries never reach the agent twice. On the reading side, each queued event carries its own event id — a later agent run should dedupe on that id before acting and acknowledge the event after handling, because delivery is at-least-once and a replay after a crash can hand back an event the run already processed. Because reading is pull-based there is no response window to trip; the risk to guard is reprocessing after a crash, and the event id plus acknowledgement covers it.
How do I trigger an AI agent when an email arrives?
An email has to be received by something always online before any agent can act on it, so the design question is what happens at arrival. Inbox APIs with webhook subscriptions push a notification to an endpoint you run, and your endpoint or scheduler starts the agent. AgentAddress takes the other half of the problem: it does not push or start anything, but every email delivered to the task's inbound address becomes an email.received event in the same ordered 30-day queue as the task's HTTP callbacks, up to 1,000 events. When your runtime or scheduler starts a later run — on a schedule, or after work that expected a reply — that run polls the queue with the one-time read token, finds the email waiting with its sender, subject, and attachment metadata, and acts on it. Use an inbox-API webhook when you want the arrival itself to start a run; use AgentAddress when the reply may arrive long after the run that asked for it has exited.
Does an agent email inbox need IMAP or SMTP support?
Only if the inbox has to be read with a mail client or a legacy script — and that is a compatibility choice, not a capability gap to fix. IMAP/SMTP exposure means the inbox speaks the human-mail protocols, which lets the same address serve a monitoring script or an IMAP-capable tool; the cost is that the agent-side consumer still has to parse raw mail itself. AgentAddress takes the code-native route instead: an inbound address whose mail is normalized into email.received events — with sender, subject, body, and attachment metadata — in the same ordered 30-day queue as the task's HTTP callbacks, read over REST or MCP with the saved read token. That fits agents that read mail from code; if your requirement is genuine mail-client access to the same inbox, pick a provider that exposes IMAP.
What happens when a webhook delivery is larger than 64 KiB?
Large payloads are handled through the 64 KiB body_url convention instead of raising a hard ingress limit. When a sender POSTs an event whose body exceeds the 64 KiB inline size, it stores the full payload somewhere the reader can reach — an S3 or GCS object with a pre-signed URL, a private blob link, or any durable HTTPS location — and sends the 64 KiB envelope with a body_url field pointing at it. The small event is what gets queued, deduplicated, and retained in the address's 30-day queue exactly like any other event; the later agent run polls the queue, reads the envelope, fetches the body_url with its own credentials, and resolves the full payload at read time. The queue never proxies or re-hosts the large object — it only carries the signed reference — so the address keeps its ordered, task-scoped shape even for events that are far bigger than a normal callback.
Can an agent receive email from the command line with curl, without a backend?
Yes, for the receiving and reply-pickup half of the job — with one boundary to know about. Creating the address is a single curl POST to the unauthenticated creation endpoint, and reading is curl too: a later run GETs the address's events URL with the saved one-time read token as a bearer header, optionally holding the request open for up to 25 seconds of long polling, and acknowledges each handled email.received event. No backend, webhook endpoint, or always-on process is involved, because the queue holds deliveries until a run asks for them. The boundary is outbound: plain-text sending and replies to verified contacts work only when the operator has configured a sending domain, so a curl-only workflow that must originate mail to arbitrary recipients needs a full inbox API instead. For the task-shaped case — give someone an address now, let a later command-line run pick up the reply — curl is enough.
Are there AgentMail alternatives for AI email workflows and automation?
Listicles of AgentMail alternatives mostly cover workflow and automation tools — help-desk agents, email-marketing platforms, and notification routers — because that is what the query is usually about. AgentAddress is deliberately outside that category: it does not run email workflows, route conversations, or automate replies. What it covers is the return path a workflow can hang on: one unauthenticated POST provisions a task-scoped inbound email address, whatever arrives becomes an email.received event in the same ordered 30-day queue as the task's HTTP callbacks, and a later agent run reads it with a one-time read token. If the agent needs to manage conversations or run workflows over mail, a full inbox API or an automation platform is the fit; if the job is staying reachable for a reply after the run that started the work has exited, that is the slice AgentAddress covers.
Which email APIs for AI agents give a personal inbox rather than just sending?
Most email APIs only let you send; the ones that also give an agent its own inbox fall into two designs. Full inbox APIs (AgentMail, InboxAPI and similar) give the agent a personal mailbox identity that can send, receive, and hold threaded conversations, and they suit agents that need to originate mail to arbitrary recipients. AgentAddress takes the return-path design instead: the agent hands out a task-scoped inbound address — an email identity scoped to one task, not a long-lived mailbox — and whatever arrives, along with the task's HTTP callbacks, is retained in one ordered 30-day queue that a later run reads over REST or MCP with the saved token. Outbound sending is not part of the default path: plain-text mail and replies to verified contacts require operator-configured sending. Pick a full inbox API when the agent needs to start conversations; pick a task-scoped return address when the job is to stay reachable for a reply after the run that asked for it has exited.