Idempotent purchase and lifecycle actions with opaque Sim7 order IDs.
Every state-changing public API request requires a unique Idempotency-Key (8–128 safe characters). Repeating the exact request returns the stored response; reusing the key for different input returns idempotency_conflict.
Completed idempotency responses are retained for seven days. After that window, use a new key only for a genuinely new operation. Uncertain operations stay locked and require support reconciliation.
Pre-allocation errors such as insufficient_funds, no_numbers_available, price_changed, or a rate/concurrency limit release the reservation. After fixing the condition, retry the same request with the same Idempotency-Key.
If a purchase result is uncertain, the key remains blocked instead of risking a second charge. Keep the original idempotency key and contact support with it; do not start a replacement purchase blindly.
After an idempotency_in_progress result for an order action, read the order to reconcile its current state. For a webhook configuration change, read /webhook and rotate the signing secret if its one-time value was lost. Purchase creation is different: never replace its key while the outcome is uncertain.
Statuses are waiting, code_received, completed, cancelled, banned, and expired. Finish is valid after a code; cancel or ban is valid while waiting, subject to the route's provider cooldown.
Order status reads use a 20-second provider-poll lease. Concurrent reads return the latest local snapshot; supplier checks are additionally capped at 60 per account per minute.