Errors and rate limits - Krino

Krino returns errors in RFC 7807 format.

{
  "type": "Request Failed",
  "title": "Necessary fields missing",
  "status": 400,
  "instance": "/api/decisions/"
}

Status codes

Code	Meaning	What to do
`200`	A decision was produced	—
`202`	Record accepted, queued for storage	Do not query it immediately
`400`	Malformed body, missing field, or wrong type	Fix the body; retrying will not help
`401`	Key missing or invalid	See Authentication
`413`	CSV file exceeded 50 MB	Split the file
`429`	Rate limit exceeded	Back off and retry
`500`	Unexpected server-side condition	Retryable

Retrying

Do not retry 400 or 401 — the same request produces the same answer. For 429 and 500, use exponential backoff (1 s, 2 s, 4 s, 8 s) with a cap on total attempts.

If the decision endpoint sits inside a payment flow, decide your retry budget up front. Timing out the payment while waiting for a decision is worse than not getting the decision. Give Krino a timeout and fall back to your own default behaviour when it is exceeded.

Rate limits

Endpoints run under a default rate-limiting policy; requests over the limit get 429. Limits are configurable in your own deployment — at enterprise volumes we tune them together during onboarding.

What `202` guarantees

When the ingestion endpoint returns 202, the payload has been validated and placed on a durable queue. The write itself is asynchronous: the record is not yet queryable when the response arrives. If you send an event and immediately ask for a decision that depends on it, that decision may not see it.