Pre-release — contact your Fortary account team for access.
The error envelope
All errors return a single top-levelerror object:
| Field | Description |
|---|---|
type | A broad, stable category — one of invalid_request, unauthorized, forbidden, not_found, rate_limited, internal_error. Good for branching your error handling. |
code | A specific, stable machine-readable code. Use this for precise handling. |
message | A human-readable explanation. May be reworded between releases — don’t match on it. |
details | Optional structured context about the error (for example, which field was at fault). |
correlationId | A unique identifier for this request. Quote it when contacting support. It mirrors the X-Request-Id response header. |
docUrl | A link to the documentation page for this code, at https://docs.fortary.io/errors/<code>. |
Branch on
type (or code) and the HTTP status, never on message. The codes are part of the contract; the wording is not.HTTP status codes
For the read-only v1 API you’ll encounter:| Status | Meaning |
|---|---|
200 | Success — body returned. |
204 | Success — no body. |
400 | Malformed request — bad JSON, a missing or wrong-typed parameter, or an unsupported filter. |
401 | Missing, invalid, expired, or revoked credential. |
403 | Valid credential, but it lacks the required scope or access for this operation. |
404 | The resource doesn’t exist or isn’t visible to this credential. See Authorization. |
413 | Request body too large. |
422 | The request was well-formed but a value was semantically invalid. |
429 | Rate limited — back off using the response headers. See Rate limiting. |
500 | An unexpected error on our side. Safe to retry after a short wait. |
503 | A dependency is temporarily unavailable; a Retry-After header tells you when to retry. |
Per-code reference
Each error includes adocUrl that points to a page for that specific code — its cause and how to resolve it — at https://docs.fortary.io/errors/<code>. Pages for the common error codes are available now; per-resource codes are added as the API surface ships.
Request identifiers for support
Every response — success or error — carries anX-Request-Id header, and error bodies mirror it as correlationId. If you need help with a specific request, include that value: it lets support trace exactly what happened.
If you send your own X-Request-Id header on a request, it’s echoed back to you in a separate clientRequestId field for your own correlation; the authoritative X-Request-Id is always generated by the API.
