Free idempotency simulator
See why retries should not become customer usage
Experiment with the exact request-level rule UsageBox uses: one key identifies one logical payload. Retry it safely, or reuse it incorrectly and see the conflict before you put the pattern into billing code.
The three outcomes
- First key + payload: accepted
- Same key + same payload: duplicate, not recounted
- Same key + different payload: HTTP 409 conflict
Request
[{"value":1}]Try this sequence: send once → send again unchanged → change only the value and send again → generate a new key and send.
Simulated meter
0 newly accepted requests
Same key + same payload
That is a retry of the same logical request. It should not create another billable event.
Same key + different payload
That is ambiguous and unsafe. UsageBox returns a conflict instead of silently choosing which version to bill.
New logical event
Generate a new key once at the billable action source, then reuse it for every transport retry of that event.
The production rule is simple
Mint one idempotency key per logical usage event. Keep it outside the HTTP retry loop. If a timeout makes you unsure whether the request landed, retry the exact same payload with the exact same key.