Usage
What the Platform Usage page shows for each product: two separate registers, what each one counts, and what a zero or an unavailable reading means.
The Usage page has two sections, one per product, which read two different registers. They are never mixed: no Transaction Intelligence request enters a Merchant API counter, and vice versa. What you read here is usage visibility, not an invoice: what is billed is read on the Billing page. See Billing.
Merchant API
The section covers the workspace's last thirty days. A table gives, for each day:
| Column | What it counts |
|---|---|
| appels (calls) | The calls settled that day |
| unités (units) | The units carried by those calls |
| resolved, partial, not_found | The calls by result |
| engine_error | Engine failures, never billed |
| 429 | Rate-limited calls |
| refresh | Refresh calls |
Below that table, Appels récents (recent calls) lists the last fifty calls: request_id, date, enrichment_id, result, call type and units. To point support to a call, quote its request_id. No descriptor and no transaction identifier appear there.
Latencies and HTTP status codes are not in this section: its register only holds settled calls. A call refused before being settled leaves no row there.
The Overview page also shows, for Merchant API, the units used and remaining in the sandbox allowance, and the last thirty days of calls by result. See Sandbox and Observability.
Transaction Intelligence
While the Transaction Intelligence sandbox is not enabled for the workspace, the section says so: there is nothing to count. Enabling it happens on the API keys page. See API keys.
Once the sandbox is enabled, the section counts every authenticated request of the workspace, with the HTTP status actually returned: total, successes (2xx), client errors (4xx other than 429), rate-limited (429, broken down by key and by workspace) and server errors (5xx). It can be read over 24 hours, 7 days or 30 days, by UTC day and by key; clicking a key filters the section on it. A request without a valid key (401), a revoked key and GET /openapi.json are never counted.
The section also restates the sandbox rate limit, per key and per workspace: it is an operational safeguard, neither a quota nor a credit. Details of operation families, retention and "not observed" days are in Usage and API keys; limits are in Rate limits.
Zero, unavailable, lower bound
The Transaction Intelligence section distinguishes three situations:
- Zero: the reading succeeded and found no request. It is a measurement.
- Unavailable: reading the register failed. The section then shows no zero; it says "usage indisponible" (usage unavailable). Reload the page; if it persists, contact support.
- Lower bound: if a key was used after the last recorded request, the section warns that the register missed requests. Its numbers are then a minimum, not an exact measurement.
Further reading
- API keys: create, filter, revoke.
- Billing: what is billed, and what is not.
- Merchant API billing: what a call costs in production.
Published on 2026-10-09 10:17 UTC (version 1).