How do I handle inbound emails with my agent?
AgentMail offers three ways to process incoming emails, each suited to different use cases.
1. Webhooks (Recommended for Production)
Configure a webhook URL and AgentMail will send a POST request to your endpoint whenever an email arrives. This is the most reliable approach for production applications.
Register your webhook via the API:
event_types is required: list every event type the webhook should receive.
Always return a 200 OK immediately and process the webhook in the background. A response slower than 15 seconds counts as a failed delivery, and AgentMail retries it. Also, filter out message.sent events to prevent your agent from replying to its own messages in a loop.
Deduplicate on event_id
Webhook delivery is at least once: a retry can arrive after your endpoint already processed the event, so the same event can reach you twice. Every payload carries an event_id that stays the same across retries and across every webhook that receives the event. Record the event_id values you have processed and skip repeats, as in the example above. Do not deduplicate on the svix-id header: it differs between webhooks registered for the same events at different levels (organization, pod, inbox).
If your endpoint goes down
AgentMail retries a failed delivery 8 times over about 27.5 hours. If deliveries keep failing for 5 days, the webhook is disabled automatically and AgentMail does not notify you: the webhook’s enabled field turns false. After you fix the endpoint, re-enable it with client.webhooks.update(webhook_id, enabled=True). Events from while it was down are not redelivered, so catch up by listing messages received since the last event you processed:
See Recovering missed events for the other options.
For local development, use ngrok to expose your local server. See the Webhook Setup Guide for full instructions.
2. WebSockets (Best for Real-Time, No Public URL)
Stream email events over a persistent connection. No public URL or ngrok needed, which makes this ideal for local development and desktop agents.
The SDK also provides a synchronous client if you prefer:
See the WebSocket Overview for more details.
3. Polling webhooks (Agents That Start and Stop)
A polling webhook queues events for your agent instead of pushing them. Your agent fetches the queued events whenever it runs and commits the ones it has processed, so nothing is lost while it is offline and nothing needs to be reachable from the internet. This fits cron jobs, serverless functions, and agents behind a firewall.
Polling webhooks are available in the US region only for now. See Polling Webhooks for how to read and commit events.
Which should I use?
For most production use cases, webhooks are recommended. They are reliable, event-driven, and integrate well with serverless platforms. If you need real-time events without exposing a public URL, WebSockets are the best option. If your agent cannot stay connected, use a polling webhook so events wait for it.
