IOSOR Learn

Rate-limit gate before you allow bursts

Prod gate: document limits and backoff before marketing “unlimited” bursts — reject and Retry-After must protect prepaid before campaigns open the tap.

Marketing “unlimited” before a rate-limit gate is how prepaid wallets meet surprise burns. Buyers need documented limits, Retry-After behaviour, and fail-closed rejects before any campaign is allowed to burst. This page is that prod gate — not the developers essay on pilot→production API limits, and not the idempotency-and-money deep dive.

Related: Pilot throughput: honest ceiling, Wallet stop-lines before production, Day-1 runway: what must be green, Shared status language for product and finance.

IOSOR is white-label prepaid. USD 20 funds a gate smoke on one key; soft review near USD 1,000/month prices “open the burst, tune later” as recon debt. Clients see white-label reject macros only.

Limits are a money gate, not a slogan

Money-affecting sends start only after the published limit window is named. Missing Retry-After, “retry until 200,” or treating 429 as soft success fails closed for campaigns — no silent queue that later drains the wallet. Catalog Live does not waive the gate. Soft USD 1,000/month treats “unlimited for launch week” as production debt; USD 20 proves one burst attempt stops with honest reject status.

What the gate checks before a burst

Gate check Pass means Fail means
Limit window documented Product and finance share the number Burst stays blocked
Retry-After honoured Clients back off Campaign cannot hammer
Over-limit → countable reject Ops can export hits Silent drop / invent success
Burst owner named Who opened the tap Folklore at 02:00
Ceiling + stop-lines aligned Same numbers as pilot ceiling Parallel “unlimited” story

Pilot ceiling first: Pilot throughput: honest ceiling. Stop-lines stay in the same runbook: Wallet stop-lines before production.

Fail closed when the gate rejects

Rejected burst traffic never invents delivered. Product and finance share reject words — not hero upstream codes: Shared status language for product and finance. Side effects after accept only; CRM “sent” before the gate manufactures double truth. Soft volume language stays blocked while a forced over-limit smoke still shows success.

Product, finance, and ops share one proof

Product: can a legitimate in-limit send pass once, and an over-limit burst stop? Finance: do limit rejects sit next to accepted debits on the same UTC day? Ops: can you export gate hits without Slack archaeology? Soft USD 1,000/month talk stays blocked until that proof is green. Runway still needs the other greens: Day-1 runway: what must be green.

Buyer checklist for the rate-limit burst gate

  1. Limit window and Retry-After written before any campaign burst?
  2. Over-limit traffic fails closed with countable reject status?

Start with IOSOR

Configure your explicit burst rate limits and window duration directly inside the IOSOR gate settings before launching high-volume campaigns. Confirm that over-limit payloads trigger an immediate, countable 429 rejection with a valid Retry-After header instead of silently queuing. Export the gate hit log from the ops console to verify that finance debits align perfectly with accepted sends.

IOSOR takeaway

Rate limits act as a hard financial safety gate rather than a cosmetic traffic guideline. When campaign traffic exceeds pre-agreed limits, failing closed immediately protects your wallet from runaway queuing costs and keeps status reporting consistent across teams.

Was this guide helpful?

Related guides