Usage and API keys

What the Platform Usage page counts for Transaction Intelligence, what it leaves out, and how to create, name and revoke a sandbox key on the API keys page.

View as Markdown

What the Usage page shows

On Platform, the Usage page has a Transaction Intelligence section. It reads a register kept by the API runtime: every authenticated request is counted there with the HTTP status that was actually returned. It counts requests, never tokens or money.

Without the Transaction Intelligence sandbox enabled for your workspace, there is nothing to count: enabling happens on the API keys page.

The summary

Five numbers, for the window you have chosen:

Number	What it counts
Authenticated requests	The total: successes + client errors + rate limited + server errors
Successes (2xx)	`201` on creation, `200` on reads, `200` on idempotent replays and `200` on coverage declarations
Client errors (4xx excluding 429)	`422`, `404`, `409`, `400`: authenticated requests, refused after the key was read
Rate limited (429)	Rate-limit refusals, split between per-key and per-workspace
Server errors (5xx)	`5xx` returned to an authenticated request

Below the summary, the same window is broken down by family: enrichments (POST /transactions/v1/enrichments), reads (GET /transactions/v1/enrichments/{enrichment_id}) and coverage windows (POST /transactions/v1/coverage-windows).

Per day (UTC)

A table gives, for every day in the window: total, successes, 4xx, 429, 5xx, then the POST / GET / coverage split. Days are UTC days, cut by the server, never by your browser's time zone. A day with no requests is a row of zeros, not a missing row.

Per key

A second table lists every Transaction Intelligence key in the workspace, revoked keys included: identifier, name, state (active or revoked), then total, successes, 4xx, 429 and 5xx over the window. A revoked key keeps its history. The identifier is the one shown on the API keys page: the prefix, the ten-character public identifier and the last four characters. The secret never appears.

Clicking a key filters the whole section to that key; an identifier that belongs to no key in the workspace is flagged, and this is not a fault.

Three windows

The section can be read over three windows: 24 hours, 7 days or 30 days. Days are UTC days. The register is kept for 35 days; beyond that, the page can no longer say anything.

Zero, not observed, unavailable

Three states that look alike, and that the page keeps apart:

Zero: a read succeeded and found no requests. It is a measurement.
Not observed: the day predates the register coming into service, or lies beyond its retention. The row says so in words, with no number. When the window starts before the effective start of observation, the summary flags it too.
Unavailable: reading the register failed. The page then shows no zeros at all; it says "usage unavailable". Reload; if it persists, contact support.

What is counted, and what is not

The register only knows an attributable request: a valid credential was presented and the rate limiter gave its verdict. From there, everything counts, whatever the outcome: a schema 422, a 404, a 409, a 400 for unreadable JSON or an invalid Idempotency-Key, a 200 idempotent replay, a 429 (counted under "rate limited").

Whatever is refused before the credential is read, or by it, is never counted:

GET /openapi.json, which is public and needs no key;
a 401: credential missing, malformed, from another family, unknown or revoked;
a 403 for an inactive workspace;
400 for an undeclared host, 415 and 413, all refused before any credential is read.

This is the rate limiter's own rule: a valid key consumes a token even when the request ends in 422, and an unknown key has no bucket. See Rate limits.

What the page is not

It is not a billing ledger. Transaction Intelligence is in sandbox: nothing is billed and nothing is drawn down. The numbers are counts of requests; they convert into nothing.

The operational rate limits come from the contract:

debit_ti_v1operational_burst_protection · token_bucket

120 / min

per key · capacity 120 · refill 2/s

600 / min

per workspace · capacity 600 · refill 10/s

« 120 requetes / minute » est traduit en seau a jetons : capacite 120 (la rafale toleree) rechargee a 2 jetons / seconde (le regime durable). Une clef au repos peut envoyer 120 requetes d'un coup, puis 2 par seconde ; sur la premiere minute apres un repos, jusqu'a 240 passent. Le workspace, lui, borne la somme de toutes ses clefs a 600 / minute (capacite 600, 10 / s) : cent clefs ne font pas cent fois la limite.

This is not: sandbox_lifetime_quota · production_usage_quota · billing_entitlement · commercial_promise

Nor is it a transaction log: no descriptor, no transaction identifier and no request body appears there. To point support at one specific request, quote the noryo-request-id from its response.

Keys on the API keys page

The API keys page carries, in its Transaction Intelligence section, everything to do with keys. A Merchant key (nry_mer_*) does not open Transaction Intelligence, and vice versa.

Enabling the sandbox

Enabling is a workspace decision, recorded in the audit log and reserved to an owner or an admin. It creates nothing beyond the right to issue nry_txn_sbx_ keys.

It first requires a complete developer profile for the workspace: identity, professional phone number, organisation, and what you are building. While anything is missing, enabling is refused and no key is issued. See Production access.

Creating a key

An authorised member of the workspace names the key, states its purpose and creates it. The full secret, nry_txn_sbx_<key_id>.<secret>, is shown once. Copy it straight away: Noryo keeps only a verifier and cannot give it back to you. Store it in a server-side environment variable (NORYO_API_KEY in our examples), never in a browser bundle, a public repository or a mobile binary.

The number of active keys is capped per workspace; the cap and the current count are shown on the page, read from the server. Revoked keys do not count. Once the cap is reached, revoke one to create another.

No live key is issued: production is not open. It is requested and reviewed, and an approval is not enough: other conditions follow it, including billing that does not exist yet. See Sandbox limitations and Production access.

Revoking a key

Revocation is immediate: from the very next request, the key returns 401 and nothing further is counted for it. Its history stays readable on the Usage page. To replace a key, revoke it and create a new one.