Operations

This section gathers what you need to run an integration without surprises: what the server guarantees when something goes wrong, and what is up to you.

What the server guarantees

• A rate-limit refusal computes nothing and bills nothing. A 429 costs less than a served request. See Rate limits.
• An engine failure is never billed or memorised. A 503 engine_error is retried with the same Idempotency-Key. See Retries.
• Settlement is atomic. The idempotency key reservation, billing and the response memory are written together: there is no moment at which the invoice would be recorded and the response lost.
• An attempt has exactly one identifier, the same in the header, the error body and Noryo's logs. See Request IDs.
• No error leaks internal information: no SQLSTATE, no table name, no stack trace, no internal hostname. See Errors.

What is not published

• No latency or availability commitment is published. Do not build your timeouts on an assumed value. See Timeouts.
• Production rate limits are not published: read Noryo-RateLimit-Limit.

The rule that makes everything else safe

Send an Idempotency-Key generated once per operation, and reuse it for every retry of that operation. With it, a retry after a timeout, a 500, a 503 or a network cut can neither duplicate an enrichment nor bill it twice. Add an external_transaction_id so that the same transaction sent again weeks later is recognised. See The two identifiers.

In this section

• Rate limits: token bucket, headers, 429 and Retry-After.
• Retries: what to retry, when, and how.
• Timeouts: what happens when a request takes long, on both sides.
• Errors: the Problem Details format and the catalogue of codes.
• Request IDs: Noryo-Request-Id, and how to use it with support.
• Observability: what you can measure, and what Noryo logs.