Skip to main content
Every error from the Niadra API has the same shape and a stable code. Your code decides by the code, never by the text of detail, which may change. The codes are versioned with the OpenAPI of /v1: a code never changes meaning within a version.

The problem document

Errors answer with Content-Type: application/problem+json, the format of RFC 9457.

The catalog

A route that needs a person, such as review verdicts, answers 403 forbidden to a source key. See Limits and conventions for the sizes. In the Python SDK, code and request_id are properties of APIError, and problem holds the parsed body. In the TypeScript SDK, NiadraAPIError has status, code, requestId and problem.

Errors inside a batch

POST /v1/batch answers 200 when every item went in and 207 when some items were rejected; POST /v1/feedback and the system webhook answer the same way. Item codes are the catalog codes plus too_large, for an item over 1 MB. One bad item never fails the batch: the valid items are stored and each rejected item comes back with its position.
A duplicate is not an error: resending a batch after a timeout is safe. The SDKs log rejected items with their code and drop them, because the same item would be rejected again.

Retries

Both SDKs give reads a short total budget of their own, so a retry never makes the agent wait past it. In the default mode a failed read resolves with an empty or last good value, and the agent carries on without memory for that turn.

Tracing a request

Send a W3C traceparent header and Niadra continues your trace; every response carries request_id. Quote the request_id when you contact us. The SDK errors expose it as request_id in Python and requestId in TypeScript.

Next steps

Limits and conventions

idempotency, pagination, rate limits and sizes.

Python SDK

the exception classes and strict mode.

TypeScript SDK

the error classes and Result.

Send a batch

the 200 and 207 answers in the API reference.