Why it matters
Retries are normal: client timeouts, queue re-delivery, webhook replays. If your system isn’t idempotent at each boundary, you will double-charge.
Practical pattern
- Require an idempotency_key on create-like endpoints.
- Persist (tenant_id, key) → resulting object id.
- On retry, return the original result (not a new one).
- Make charge creation idempotent too (charge_key per customer + period).
Neruba scopes idempotency keys by tenant/project to prevent cross-tenant collisions.
Want the full sequence by email? Subscribe to Neruba Engineering Notes.