An address (also called an inbox) is a specific mailbox on one of your domains, like support@yourdomain.com. Addresses control what happens when mail arrives.

​
Routing precedence

When a message arrives for local@yourdomain.com, Inboundr resolves it in this order:
1

Explicit address route

If you created an address for that exact local part, its rule wins. If the address has an endpointId, the message is delivered to that webhook. If not, it’s store-only (kept for retrieval, no webhook).
2

Domain catch-all

Otherwise, if the domain has a catch-all endpoint, the message is delivered there.
3

Store-only default

Otherwise the message is still parsed and stored — readable via the API and MCP — it just doesn’t trigger a webhook.
An explicit address route claims that local part either way — even a store-only address (one with no endpoint) opts that address out of catch-all.

​
Store-only vs. delivered

Store-only

Omit endpointId. Mail is parsed and kept; read it with list_emails / the emails API. Ideal for agents that poll or read on demand.

Delivered

Set endpointId to a webhook endpoint. Each message is POSTed to your URL as a signed email.received event in real time.

​
Creating an address

The localPart is everything before the @ (1–64 chars, lowercased). Omit endpointId for a store-only inbox.
You don’t have to create an address for every mailbox. With catch-all on a verified domain, anything@yourdomain.com already works — create explicit addresses only when a specific mailbox needs different routing.

Addresses API

Create and list address routes.

​
Attaching a webhook

An address can attach to one webhook endpoint, which gets its own delivery with its own retries.
If you need to reach more than one destination, fan out from your own handler. An empty endpointIds (or omitting it) makes the address store-only — mail is kept and readable through the API and MCP, but nothing is delivered. The single-destination endpointId spelling is still accepted and behaves as a list of one.