200 with data, a 4xx validation error, or a 5xx
downstream failure, the response body has the same outer shape:
request_id at the top level, plus either data (on success) or error
(on failure).
Success
Error
error.code is a stable machine-readable identifier — use it for branching
in your code. error.message is human-readable and may be polished over
time, so don’t pattern-match on it.
request_id is in every response. Include it when you open a support
ticket; it lets klikit pinpoint the exact request in our logs. Treat its
format as opaque — the production format today is 32-char hex, but
older paths and the development environment may return UUID-prefixed
strings like req_e9f2b838-38e9-43ba-9e30-9b747da67d9f. Don’t validate
it client-side.
Status code conventions
A non-2xx response always has an
error object. A 2xx response always
has a data field (it may be null, {}, or []).
Pagination — note the inconsistency
Endpoints that return lists wrap theirdata in a paginated object with
page, size, and total. The key holding the actual items varies by
endpoint:
This is an artefact of partner-api forwarding to multiple backend services
that each have their own conventions. We don’t normalise — what you see in
the API Reference is what the service
returns. Treat the shape per endpoint, not in general.