API-limieten van piloot naar productie: backoff zonder prepaid te verbranden

Een 429 is geen uitnodiging de send-API te hameren tot iets doorgaat. Op prepaid is een retrystorm een walletevent: dubbele OTP, gestapelde alerts, ongepaarde ledgerregels. Limieten bestaan zodat product, engineering en finance één plafond delen. Van piloot naar productie is niet «de cap weg» — gecontracteerde limieten, backoff die idempotentie eert, gescheiden sandbox- en productiesleutels, en een webhook-replayvenster dat niet dubbel debiteert. Zie idempotentie, retries en geld.

IOSOR is white-label prepaid: geauthenticeerde calls, correleerbare debits, clientveilige fouten die nooit vreemde merklading dumpen.

Limieten beschermen prepaid, het is geen bug

Limieten begrenzen hoeveel geaccepteerde intents de wallet per venster raken — niet hoeveel TCP-pogingen de balancer maakte. Documenteer venster (per sleutel, account, bestemmingsklasse), code en Retry-After. Een client die 429 als «probeer harder» leest, rent tegen finance. Exporteer limietrejects naast geslaagde debits.

Backoff zonder tweede debit: limieten met idempotentie

Exponentiële backoff zonder idempotentiesleutel maakt van een trillend net twee OTP’s. De sleutel is uniek per business-intent, niet per TCP-poging, en geeft hetzelfde geaccepteerde resultaat binnen een duidelijke TTL. Gebruikersresend is een andere productactie met eigen limiet. Low-balance-stop geldt: een retry mag een lege wallet niet doorboren.

Pilootlimieten versus productielimieten

Pilootkeys moeten strakker zijn: laag volume, snelle zichtbaarheid, goedkope fouten. Productielimieten zijn gecontracteerd voor corridors die u echt draait. Een plafond verhogen is een accountwijziging met eigenaar. Loadtests horen op sandboxkeys; een productiesleutel in een soak verbrandt prepaid. Beloof geen productie-QPS zolang de cataloguscorridor in setup is.

Sleutels en webhook-replay in dezelfde cutover

Send-limieten redden u niet als de webhook-consumer DLR dubbel verwerkt. Cutover: sandboxverkeer bevriezen, productiesleutels uitgeven, webhooks naar productieconsumers wijzen, handtekeningen verifiëren, replayvenster begrenzen, dan één echte intent. Een herhaalde callback om 02:00 moet no-op zijn, geen tweede debit. Gescheiden secrets; nooit in een ticket plakken.

Rode vlaggen

• «Retry tot 200» zonder idempotentiesleutel
• 429 als zacht 200
• Productiesleutel in een loadtest of sandbox-webhook-URL in productie
• Replayvenster in weken, of ongetekende callbacks «voor de piloot»
• Gebruikersresend in het auto-retrybudget gemengd
• Clientfouten die ruwe upstreamcodes dumpen

Starten met IOSOR

Schrijf het limietvenster op — per sleutel, account of bestemmingsklasse — en de Retry-After die u eert. Forceer een 429, wijk terug en probeer dezelfde intentie opnieuw met dezelfde Idempotency-Key. Het ledger moet één debit tonen. Wissel de sandboxsleutel voor de productionsleutel voordat u een plafond optilt.

• Correlatie-ID's traceren van API-verzoeken naar DLR-webhooks
• Simuleren van DLR-latentie en fouten bij lokale tests

IOSOR takeaway

Doe: behandel 429 als een pauze met Retry-After, niet als een zacht succes. Koppel elke backoff aan de oorspronkelijke sleutel zodat prepaid één geaccepteerde intentie ziet.

Niet doen: productielimieten op een loadtestsleutel verhogen, of zonder sleutel tot 200 hameren tot de portemonnee extra verbruik lijkt.