Authentication

Every API request, and every MCP call, authenticates with an API key sent as a bearer token.

Authorization: Bearer inb_xxxxxxxxxxxxxxxxxxxxxxxx

Creating keys#

Create keys in the console under API keys. The full key is shown only once, when you create it, so copy it then. Inboundr stores only a hash, so a lost key can't be recovered; revoke it and create a new one.

Keys start with inb_. Treat them like passwords: never commit them or expose them in client-side code.

Scopes#

Every key is one of two kinds, chosen when you create it:

Read-only is the default, and the right choice for most keys. An agent that polls an inbox, a dashboard or a sync job doesn't need to create resources or change where mail is routed, and a read-only key that leaks can't do either.

The HTTP method decides: GET and HEAD are reads, and everything else is a write. A read-only key that attempts a write gets a 403, and the request isn't carried out:

{
  "error": "This API key is read-only. Create a key with full access to send email or change configuration."
}

Over MCP, where every call is a POST, the tool decides instead. create_inbox, create_shield_rule and delete_shield_rule need full access; every list_* and get_* tool works with a read-only key.

Keys created before scopes existed have full access, so existing integrations kept working. If you have long-lived keys that only ever read, replacing them with read-only keys takes one deploy and removes most of the damage a leaked key could do.

Using a key#

curl https://inboundr.net/api/v1/domains \
  -H "Authorization: Bearer $INBOUNDR_API_KEY"

A key belongs to the account that created it, and every request acts only on that account's data.

Revoking keys#

Revoke a key from the console at any time. Revocation takes effect immediately: later requests with that key return 401.

Errors#

{ "error": "Invalid API key" }