API rate limits from pilot to production: backoff without burning prepaid

A 429 is not an invitation to hammer the send API until something sticks. On prepaid, a retry storm is a wallet event: duplicate OTP, stacked alerts, unmatched ledger rows. Rate limits exist so product, engineering, and finance share one ceiling. Pilot to production is not “remove the cap” — contracted limits, backoff with idempotency, separate sandbox and production keys, and a webhook replay window that does not double-debit. Pair with idempotency, retries, and money.

IOSOR is white-label prepaid: authenticated calls, correlatable debits, client-safe errors that never dump foreign brand payloads. Catalog live vs in setup is independent of how hard you retry — a corridor in setup does not become Live because the client looped. Near USD 1,000+ monthly usage, retry budgets and key cutover enter commercial review. Keep sandbox vs production cutover and webhook signature and replay window in the same runbook.

Rate limits protect prepaid, they are not a bug

Limits bound how many accepted intents hit the wallet per window — not how many TCP attempts the load balancer made. Document the window (per key, account, destination class), the status code, and Retry-After. A client that treats 429 as “try harder” races finance. Export rate-limit rejects next to successful debits. Catalog live still stops at the published ceiling; in setup is not an unlimited sandbox.

Backoff without a second debit: pair limits with idempotency

Exponential backoff without an idempotency key is how a flaky network becomes two OTPs. The key is unique per business intent, not per TCP attempt, and returns the same accepted result inside a clear TTL. User resend is a different product action with its own limit. Stop-on-low-balance still applies: a retry must not punch through an empty wallet.

Pilot limits versus production limits

Pilot keys should be tighter: low volume, fast visibility, cheap mistakes. Production limits are contracted for corridors you actually run. Raising a ceiling is an account change with an owner.

Keys and webhook replay belong in the same cutover

Rate limits on send do not save you if the webhook consumer double-processes DLR.

Red flags

• “Retry until 200” with no idempotency key
• 429 treated as a soft 200
• Production key in a load test or sandbox webhook URL in production
• Replay window measured in weeks, or unsigned callbacks “for the pilot”
• User resend mixed into auto-retry budget
• Client-facing errors dumping raw upstream codes

Start with IOSOR

Write down the limit window — per key, account, or destination class — and the Retry-After you will honour. Force a 429, back off, then retry the same intent with the same Idempotency-Key. The ledger must show one debit. Swap the sandbox key for the production key before you raise any ceiling.

IOSOR takeaway

Do: treat 429 as a pause with Retry-After, not as a soft success. Pair every backoff with the original key so prepaid sees one accepted intent.

Don't: raise production limits on a load-test key, or hammer until 200 without a key until the wallet looks like extra usage.