Skip to main content
The API uses conventional HTTP status codes. A 2xx means the request did what it said. A 4xx means something about the request or the record stands in the way, and the body says what. A 5xx means the Platform failed, and the body says nothing about your request. Every refusal is one envelope. Branch on code, retry and details. The error sentence is written for a person and may be reworded without notice; nothing else in the envelope ever is.
Error shape

What to do next

Details

The keys are a closed set, each present exactly where the kind of refusal carries it. Every value is a string.

The request identifier

Every response carries Request-Id — successes, refusals and failures alike — and every refusal carries the same value as request_id. It is the identifier on the Platform’s own request log: quote it to name a request, above all a 500, whose body says only that the request could not be served. You may send your own identifier in Request-Id; it comes back as Caller-Request-Id and is recorded beside the Platform’s, never in its place.
The catalogue of codes is append-only. A published code is never renamed and never reused for a different kind of refusal. Treat a code you do not recognise as a new refusal, not as a fault in your client.

Status codes

A 409 is never a defect of your request. It says the record already holds something the request contradicts: a receipt on a loan you want to cancel, a cancellation under a reference you reused, a write-off in force. Read the message, act on the record, then send the request again.

Requests and access

Products

Lookup keys

Two codes are retired on this surface and are never reassigned. invalid_name was answered until 2026-09-11, when a product configuration stopped carrying a name. invalid_identifier and conflicting_configuration were answered for one day, 2026-09-11 to 2026-09-12, while a tenant stated its configuration’s identifier; the Platform composes it now, so neither can be raised on a configuration. invalid_identifier is unchanged on Clients, where it always belonged, and is answered for a lookup key — your own word, not a configuration’s identifier.

Clients

Loans: issuance

Under a facility

The client guards

Held at every issuance and preview where the configuration version states them, over the Client’s whole book on the anchor, whatever facility the Loan draws from.

Loans: acts

Receipts

Company profile

Credit policy and decisions

These are answered when a policy is authored or a credential is managed at the Console, and never by the tenant API.

Retries

Read retry rather than the status. The status still classes a code you do not know, roughly so: Requests that create records are safe to repeat as sent. An issuance, an act or a receipt repeated under its own reference answers 200 with the record on file — and where your response was lost, read the record by its reference before you resend. A product creation repeated under its Idempotency-Key answers the recorded outcome. See What is safe to retry.