Usage metering API
POST the event once, safely retry the logical request with the same idempotency key, and keep an independent usage record that does not disappear when you change billing providers.
Create a meter for requests, tokens, tasks, seats or another quantity. The minimum event only needs a value when the account has one unambiguous metering context.
Give each logical request its own Idempotency-Key and reuse that key only when retrying that same request. Transport retries should not become extra customer usage.
UsageBox preserves event history alongside rollups so a customer dispute can be investigated from the underlying records rather than from an invoice total alone.
Usage metering has to define what happens when an event arrives after the period it belongs to. The policy belongs in the meter, not in ad-hoc invoice code.
Use rollups and activity views to verify what landed before a billing system turns quantities into money.
The metering ledger is independent from pricing, tax, invoicing and payment collection, so the same measured quantity can feed the billing stack you choose.
Product boundary
That boundary is intentional. UsageBox is responsible for trustworthy usage evidence and aggregation. Your billing system remains responsible for converting that quantity into money and collecting it.
Choose the usage signal, inspect the exact payload, then create a free key only when the contract fits your integration.