# 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.

## What the Usage page shows

On Platform, the [Usage](https://platform.noryo.app/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](https://developer.noryo.app/en-GB/transaction-intelligence/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_v1` — operational_burst_protection · token_bucket

- per key: 120 requests / minute (capacity 120, refill 2/s)
- per workspace: 600 requests / minute (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.

It 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](https://platform.noryo.app/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](https://developer.noryo.app/en-GB/transaction-intelligence/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](https://developer.noryo.app/en-GB/transaction-intelligence/sandbox-limitations) and [Production access](https://developer.noryo.app/en-GB/transaction-intelligence/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.

## Further reading

- [Authentication](https://developer.noryo.app/en-GB/transaction-intelligence/authentication): the shape of the credential and the `Authorization` header.
- [Rate limits](https://developer.noryo.app/en-GB/transaction-intelligence/rate-limits): token bucket, `429` and `Retry-After`.
- [Errors](https://developer.noryo.app/en-GB/transaction-intelligence/errors), including [`invalid_api_key`](https://developer.noryo.app/en-GB/transaction-intelligence/errors/invalid_api_key) and [`rate_limited`](https://developer.noryo.app/en-GB/transaction-intelligence/errors/rate_limited).
- [Quickstart](https://developer.noryo.app/en-GB/transaction-intelligence/quickstart): from your Noryo identity to a first enrichment, then to the Usage page.

---

Canonical page: https://developer.noryo.app/en-GB/transaction-intelligence/usage-and-api-keys