https://apis.cativalab.digital/tenant/api/v2. Learn the format once and you handle errors from any endpoint the same way.
This page covers three things: the error shape, the code catalog with a real example of each, and the rate-limit contract (429 with Retry-After).
The JSON responses here are illustrative so you understand the format. The authoritative schema for each endpoint (exact fields, types, possible codes) lives in the API Reference tab.
Why a single error format
Without a standard, each endpoint would invent its own way to report failure, and your code would need a different parser per route. With RFC 7807, you write one error handler that reads the same fields (type, status, title, detail, traceId) for any 4xx or 5xx response.
Standard error shape
Per-field validation errors
For validation responses, an additionalerrors field may be populated with per-field errors in the format Dictionary<string, ProblemDetailsFieldError[]>. Each key is a request field name and the value is the list of problems for that field:
errors keys to highlight the offending field in your form, and each item’s code to map the translated message you show the user. Never rely on the English message for logic.
HTTP code catalog
One example per code
Open each code to see a concrete error and its typical cause.400 Validation Error (missing required field)
400 Validation Error (missing required field)
403 Forbidden (no permission for the resource)
403 Forbidden (no permission for the resource)
404 Not Found (resource does not exist)
404 Not Found (resource does not exist)
id in the URL doesn’t exist in this tenant, or the resource was removed. Confirm the identifier. Remember IDs are unique per tenant, so an id from another community returns 404 here.422 Unprocessable Entity (domain rule violated)
422 Unprocessable Entity (domain rule violated)
detail, fix the state, and only then retry.429 Too Many Requests (rate limit)
429 Too Many Requests (rate limit)
Retry-After header with the number of seconds to wait. See Rate limits for the retry pattern.500 Internal Server Error (Cativa-side failure)
500 Internal Server Error (Cativa-side failure)
traceId so the team can correlate it with internal logs.Rate limits
The Cativa API follows the standard rate-limit contract: when you exceed what’s allowed, it responds429 Too Many Requests with a Retry-After header telling you how many seconds to wait before trying again.
Today the rate limit is not yet enforced per key in v1. In practice, you’re unlikely to see
429 under normal use. Even so, build your client to honor 429 and Retry-After now: the contract is stable and enforcement can be turned on without an API change. Don’t hardcode limit numbers in your code, just obey whatever Retry-After the response carries.Handling 429 with Retry-After and exponential backoff
The golden rule: on429, wait as long as Retry-After says. If it’s absent, fall back to exponential backoff with jitter. The same pattern serves 500, 502, 503, and 504.
Anti-pattern: ignoring traceId in logs
How to report an error
When opening a ticket at dev@cativa.digital, always include:- The
traceIdreturned in the error response body. - The
typeand thestatusof the error. - A sample of the request (URL, method, relevant headers, without exposing the full key).
- Approximate time, with timezone, when the error happened.
Next steps
Identity and Users
Where you’ll see
400 Validation Error for an invalid field most often.Webhooks
How
X-Cativa-Execution-Id helps you deduplicate redelivered webhooks, and the same retry curve applied in reverse.First API call
Make your first authenticated request and see a success response before handling errors.
API Reference
The authoritative schema for each endpoint, with the error codes possible per route.
