Errors
Every AI Inbx error code in the problem+json body, what each one means, how to recover from it, and which failures are worth retrying.
Every failure answers with application/problem+json (RFC 9457):
{
"type": "https://docs.aiinbx.com/problems/invalid_request",
"title": "Unprocessable Content",
"status": 422,
"detail": "Request body is invalid",
"code": "invalid_request",
"request_id": "8f2c4a1b-...",
"issues": [
{ "path": "to.0", "message": "Invalid email address" },
{
"path": "subject",
"message": "String must contain at most 998 character(s)"
}
]
}
codestring
The stable, machine-readable identifier. Branch on this, never on `detail`.
stringstatusnumber
The HTTP status, repeated in the body.
numbertitlestring
The standard reason phrase for the status.
stringdetailstring
A human-readable explanation. Wording may change — don't parse it.
stringrequest_idstring
Also on the X-Request-ID header. Quote it when reporting a problem.
stringtypestring
A URI for the code — it resolves to this page.
stringissues?object[]
Field-level validation failures: a `path` and a `message` each.
object[]Handling them
import { APIError, NotFoundError, RateLimitError } from "aiinbx"
try {
await aiinbx.emails.send(payload)
} catch (error) {
if (error instanceof NotFoundError) return null
if (error instanceof RateLimitError) return scheduleRetry()
if (error instanceof APIError) {
console.error(error.status, error.code, error.requestId)
if (error.code === "invalid_request") {
console.error(error.body.issues)
}
}
throw error
}from aiinbx import APIStatusError
try:
client.emails.send(payload)
except APIStatusError as error:
print(error.status_code, error.request_id)
print(error.body["code"], error.body.get("issues"))Retry or not
| Status | Meaning | Retry? |
|---|---|---|
400 |
Malformed request | No — fix the request |
401 |
Missing or invalid key | No |
402 |
The plan doesn’t cover it | No — read code first |
403 |
Key lacks the scope | No |
404 |
No such resource | No |
409 |
Conflicts with current state | No — read code first |
413 |
Payload too large | No |
415 |
Body isn’t JSON | No |
422 |
Failed validation | No — read issues |
429 |
Budget spent or provider throttling | Yes, after Retry-After |
500 |
Something broke on our side | Yes, with backoff |
502 |
Upstream mail provider failed | Yes, with backoff |
503 |
Temporarily unavailable | Yes, with backoff |
Both SDKs already retry 429 twice, and network failures, 408, 409 and 5xx twice when the retry cannot act twice — a GET, PUT or DELETE, or a request with an idempotency key — with bounded exponential backoff, honoring Retry-After. Tune with maxRetries / max_retries.
Codes
Grouped by what actually went wrong.
Authentication and authorization
unauthorized
401 — no Authorization header, a malformed one, or a deleted key. The response carries WWW-Authenticate: Bearer. Check that the key is being read from the environment and hasn’t been deleted. See Authentication.
forbidden
403 — the key is valid but its scope doesn’t cover this operation. A read key can’t send; a sending key can’t change configuration. Retrying won’t help; use a key with the right scope.
workspace_required
400 — an access token from a CLI or MCP sign-in reaches several workspaces and the request named none. Send AIInbx-Workspace with an id from GET /workspaces. API keys belong to one workspace and never see this.
shared_apps_disabled
403 — mailboxes.connect was called without an app_id. Connecting without one isn’t available: register your own OAuth app and pass its ID.
Plan and allowances
plan_required
402 — the workspace has no plan, and a workspace without one can’t send or create anything: domains, mailboxes, pacing rules, API keys, spaces, webhook endpoints, OAuth apps. Receiving is not affected. Choose one in the console’s billing settings. Retrying won’t help until then.
allowance_reached
402 — the plan’s allowance for this is used up; detail says which. Emails are counted per month: upgrade, turn on extra usage in billing settings, or wait for the month to turn. Custom domains, mailboxes and active custom pacing rules are counted as held: delete a domain, disconnect a mailbox or disable a rule to free one, or upgrade. Subdomains under a wildcard, the provided domain and its ceilings are never counted, and reconnecting a mailbox that is active or needs_reauth takes nothing new.
Request format
unsupported_media_type
415 — an operation that accepts a JSON body was called without Content-Type: application/json. Bodyless operations do not require this header.
invalid_json
400 — the Content-Type said JSON but the body didn’t parse. Usually truncation or a stray trailing comma.
invalid_request
422 — the body parsed but failed validation. issues names each offending field with a path and a message. Also 400 from a few operations that validate outside the body schema.
invalid_query
400 — a query parameter was rejected: an out-of-range limit, an unknown status, a malformed address filter. issues names the parameter.
invalid_cursor
400 — the cursor isn’t a cursor this endpoint issued. Cursors aren’t portable between endpoints; use the next_cursor from the same list. See Pagination.
invalid_thread_id
400 — the thread_id isn’t a well-formed thread ID (thr_ plus 32 hex characters).
invalid_idempotency_key
400 — the Idempotency-Key header is empty or longer than 255 characters.
method_not_allowed
405 — the path exists but not for this HTTP method.
no_body
400 — a request that requires a body arrived without one.
Content
no_recipients
400 — to is empty.
recipients_suppressed
400 — every to address is suppressed, so there is nobody left to send to. On a partial send the response’s suppressed array tells the same story less severely. An invitation to a suppressed address fails the same way, and nothing is created. Retrying will not help.
sender_unknown
400 — the from address is on no domain and no connected mailbox of the workspace. Add its domain, or connect the mailbox and check it’s active. A domain the workspace has but hasn’t verified gets domain_unverified instead. It also comes when the address now belongs to another space than the one the send is held to — an agent inbox, or mail scheduled before its domain moved.
tracking_unavailable
400 — the send asked for tracking.opens or tracking.clicks from a connected mailbox. Only mail sent from a domain is tracked; drop tracking, or set both to false.
too_many_recipients
400 — more than 100 addresses in to, cc, bcc, or reply_to. Split the send.
unsubscribe_single_recipient
400 — a send marked unsubscribe: true has more than one recipient across to, cc and bcc. The unsubscribe link is personal; send one message per recipient.
attachments_too_large
413 — the attachments given in one request decode to more than 3 MB in total, or, on PATCH /emails/{id}, the files the email would carry come to more than 7 MB together. Large files belong behind a link. (More than 20 attachments is invalid_request.)
State conflicts
not_found
404 — no such resource in this workspace. Also what you get for an ID of the wrong type, since IDs are type-tagged, and for a space_id or space that names no space of the workspace.
thread_not_found
404 — the thread doesn’t exist or isn’t yours. Check the thread_id came from this workspace.
thread_empty
409 — a forward was asked of a thread with nothing sent or received on it yet — only scheduled or canceled messages. There is nothing to forward until a message has left or arrived.
not_prepared
404 — the attachment has no prepared text. Either its type is unsupported, extraction failed, or preparation hasn’t finished. The original is still downloadable — see Attachments.
not_scheduled
409 — cancel or PATCH /emails/{id} was called on a message that is neither scheduled nor a draft any more. It has already begun sending, or was canceled or discarded. See Scheduling and Drafts.
not_draft
409 — POST /emails/{id}/send was called on a message that isn’t a draft — it was sent already, or discarded. See Drafts.
attachment_not_found
422 — an edit kept an attachment, by { id }, that isn’t one of this email’s. Keep only ids from the email’s own attachments.
unsubscribe_recipient_fixed
409 — an edit changed the recipients of an unsubscribable email. Its unsubscribe link was made for the one recipient it was written to; send anyone else a new email.
idempotency_key_reused
409 — this Idempotency-Key was used with a different body. Either the key is being reused across genuinely different sends, or the body isn’t as deterministic as you think (a timestamp in the subject will do it). See Idempotency.
domain_unverified
409 — the from address is on a domain of the workspace whose DKIM identity isn’t verified, or has lost verification. The message names the domain. Run domains.verify, then domains.diagnostics to see which records are missing and what else in the zone is in the way. A scheduled or queued email whose domain loses verification before it leaves fails, with the same message on its timeline. See Domains.
domain_taken
409 — the space already has this domain (or the workspace, for a domain without a space_id). saas.com and *.saas.com are one identity, so either one takes the other. Another space or workspace having the name is not an error: whoever’s DKIM record DNS carries sends as it — see Moving a domain.
reserved_subdomain
409 — the name is bounces. under a wildcard, which is where that wildcard’s return path lives. Pick another label.
reserved_domain
409 — the name is under aiinbx.app. Every workspace is given one name there, <slug>.aiinbx.app, and nobody adds another — see Your provided domain.
domain_platform
409 — the domain is the one the platform sends its own mail from, and cannot be deleted. Only ever seen by the platform’s own workspace.
domain_provided
409 — the domain is the one the workspace was given. It came with the workspace and cannot be deleted; it goes when the workspace does.
rule_builtin
409 — the pacing rule came with the workspace. The provided domain’s ceilings cannot be changed, switched off or deleted.
slug_taken
409 — the slug is claimed. OAuth app slugs are globally unique because they form the hosted connect URL; workspace slugs because they form the console URL. Pick another one.
external_id_taken
409 — another space in the workspace already has that external_id. One space per customer is the point of the field; find the existing one with GET /spaces?external_id=. See Spaces.
mailbox_inactive
409 — the mailbox isn’t active. Check its state: needs_reauth means the customer has to reconnect, disconnected means it’s gone. See Mailboxes.
mailbox_space_conflict
409 — the mailbox can’t be connected in this space. Either it is already connected in another space (a mailbox’s space is fixed when it is first connected, so reconnect it through a URL minted for that space), or its address is on a domain verified in another space, which decides the address’s space — connect it there. See One address, one space.
invalid_domain
400 — the domain name isn’t a valid registrable domain.
invalid_webhook_url
400 — a webhook endpoint url isn’t one events can be sent to: not an absolute URL, not https, carrying credentials, on a port other than 443, or resolving to anything but public addresses (localhost, loopback, private and link-local ranges are refused). detail says which.
unknown_region
400 — region isn’t one of eu-central-1 or us-east-1.
region_fixed
409 — the domain is verified, or is a subdomain, and its region no longer moves. A verified domain changes region by being deleted and added again; a subdomain is handled wherever its wildcard is. See Regions.
OAuth flow
invalid_state
400 — the OAuth callback’s state parameter didn’t validate. Usually a link opened out of context; start the connect flow again.
expired_state
400 — the connection URL expired, was already used, or was never one of ours. They’re short-lived and single-use: good for ten minutes, spent when the person approves — redirect the customer, don’t email them the link. Answered as JSON on our callback page rather than on return_to, which went with the state.
invalid_tenant
400 — the Microsoft tenant on the OAuth app doesn’t match the account that authorized. Check the tenant restriction.
invalid_return_url
400 — a return_urls entry on an OAuth app isn’t one a connect link could return to: not an absolute URL, not https (plain http is allowed on localhost), carrying credentials, or carrying a #fragment. At most 20 per app.
return_url_not_registered
400 — a connect link was opened with a return_to the app hasn’t registered. Add it to the app’s return_urls — matched on origin and path, so one entry covers every query string. The server-side mailboxes.connect call isn’t held to the list, since it’s authenticated.
connect_unavailable
503 — the store that holds a connection URL’s state while the person is at the provider isn’t answering, so mailboxes.connect, a connect link or the callback can’t go on. Nothing was spent; retry with backoff, or send the person through the flow again.
Upstream and server
too_many_requests
429 — the workspace’s request budget is spent, too much of it is in flight, or the platform is at capacity; detail says which. The response carries Retry-After in seconds and the RateLimit-* headers. Wait that long and retry — both SDKs do so automatically. Sustained 429s mean the integration is faster than the budget: pace it from RateLimit-Remaining, or ask for a larger budget.
rate_limited
429 — an upstream mail provider is throttling. Not the workspace’s budget: that is too_many_requests. The response carries Retry-After in seconds. Wait that long and retry — both SDKs do so automatically.
send_failed
502 — the provider rejected the message at hand-off. detail carries what it said. Retryable, but if it repeats for the same message the content or sender is the problem.
provider_error
502 — a mail provider (Gmail, Microsoft Graph, the sending backend) failed. Retry with backoff.
internal_error
500 — something broke on our side. The request_id is already logged; quote it if it persists. Retry with backoff.
Debugging
Read `code`, not `detail`
code is stable. detail is prose and may be reworded.
For 422, read `issues`
Each entry has a path into your request body and the reason it failed.
Keep `request_id`
Log it beside your own trace ID — or send your own via
X-Request-ID so they’re the same
value.
Check the scope for a 403
A 403 after a working 200 on a read endpoint is almost always a key
scoped too narrowly.