Inboundr has a small object model. Learn these five nouns and the rest of the docs falls into place.

​
The journey of a message

Here’s what happens the moment someone emails an address on your domain:
1

Routing — where does it go?

Inboundr resolves the recipient in order: an explicit address route wins; otherwise the domain’s catch-all endpoint; otherwise it’s kept store-only. See Addresses & routing.
2

Parsing — turn MIME into JSON

The raw message is parsed into an email: from/to, subject, text and HTML bodies, attachment metadata, and SPF/DKIM/spam verdicts.
3

Threading — attach it to a conversation

Using the Message-ID / In-Reply-To / References headers, the email is placed on a thread — a new one, or the existing conversation it belongs to.
4

Surfacing — hand it to your code

If the route has an endpoint, a signed webhook fires. Either way the email is stored and readable via the REST API and MCP.

​
Two ways to consume mail

Inboundr never makes you choose a single integration style — pick per address, or use both at once.

Push (webhooks)

Route an address (or catch-all) to an endpoint. Inboundr POSTs each message to your URL in real time. Great when you run a server.

Pull (store-only)

Leave an address without an endpoint. Mail is parsed and stored; read it when you act with list_emails / GET /v1/emails. Great for agents and scripts.

Next: Domains

Start at the root of the model — registering and verifying a domain.