Skip to main content
Every error response from the Cativa API follows the same format, based on the RFC 7807 Problem Details standard. This holds across the whole public API, served at 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 additional errors 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:
Use the 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.
Typical cause. You sent the request without a required field, or with a malformed body. Fix the payload before retrying. Repeating the same request won’t change the result.
Typical cause. The Authorization: Bearer cativa_live_... header is missing, the key was revoked, or the OAuth access_token expired. Don’t enter a retry loop. Generate a new credential or refresh the token and make the call once.
Typical cause. The credential is valid but lacks permission for that operation (for example, a key without the admin role attempting an admin-only operation). Confirm you’re using the right base URL and a credential with the right scope.
Typical cause. The 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.
Typical cause. The request is well-formed but breaks a business rule (assigning a badge the user already has, enrolling into a closed course, and so on). Read detail, fix the state, and only then retry.
The response includes a Retry-After header with the number of seconds to wait. See Rate limits for the retry pattern.
Typical cause. Something failed inside Cativa. Retry with exponential backoff. If the error persists, open a ticket with the 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 responds 429 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: on 429, 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.
Never blindly retry a 4xx other than 429. A 400, 401, 403, 404, or 422 won’t change if you repeat the same request. Retrying only makes sense for 429 and the 5xx range.

Anti-pattern: ignoring traceId in logs

Always log traceId together with any API error you catch. Without it, the Cativa support team cannot investigate your case. It’s like asking for help without saying what error happened. Include traceId, HTTP status, and type in your logger from day one.

How to report an error

When opening a ticket at dev@cativa.digital, always include:
  1. The traceId returned in the error response body.
  2. The type and the status of the error.
  3. A sample of the request (URL, method, relevant headers, without exposing the full key).
  4. Approximate time, with timezone, when the error happened.
Those details let the team correlate with internal logs quickly.

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.