Error response format
The shape of every error response and what each status code means.
Every error response is JSON with the same three fields:
{
"statusCode": 404,
"message": "Contact not found",
"error": "Not Found"
}message is usually a string, but for request-body validation failures it's an array
of every field that failed validation at once (not just the first one):
{
"statusCode": 400,
"message": ["email must be an email"],
"error": "Bad Request"
}Status codes you'll actually see
| Status | Meaning | Typical cause |
|---|---|---|
400 | Bad Request | Request body failed validation — check message for which field(s) |
401 | Unauthorized | Missing/invalid/revoked API key, or no session cookie |
403 | Forbidden | Authenticated, but not allowed to do this — e.g. "Only the tenant owner can do this" on team-management routes |
404 | Not Found | The resource doesn't exist, or doesn't belong to your tenant (Threadliner returns 404, not 403, for cross-tenant access — it doesn't confirm another tenant's resource exists at all) |
429 | Too Many Requests | See Rate limits |
There's no separate application-level error code system beyond the HTTP status —
error is just the standard reason phrase for that status code, not a distinct
machine-readable error type. If you need to branch on error type in code, branch on
statusCode.
Was this page helpful?
Last updated on