[ blog · deep-dive ]7 min read

Waarom API's alleen bij succes zouden moeten afrekenen — het pleidooi voor HTTP 200-facturering

Sarah Choy·Gepubliceerd op 3 mei 2026·7 min leestijd

De meeste API's rekenen elke factureerbare call af. AI-agents proberen voortdurend opnieuw bij instabiele upstream-diensten — wat betekent dat het oude 'altijd afrekenen'-model in feite veerkracht belast. Hier lees je het pleidooi voor alleen afrekenen bij HTTP 200, en wat het verandert aan hoe je agents ontwerpt.

TL;DR

• •AI-agents proberen terecht opnieuw bij tijdelijke fouten (5xx, timeouts, rate limits). Onder 'altijd afrekenen'-facturering is elke poging een echte kostenpost — waardoor een upstream met 99,5% uptime tijdens die slechte 0,5% een kostenboete van 5× oplevert.
• •'Alleen afrekenen bij HTTP 200' brengt de prikkel van de provider op één lijn met die van de klant: providers lossen instabiliteit op, klanten betalen er niet voor.
• •Het ontsluit ook ontwerppatronen — agressieve retry-budgetten, optimistisch prefetchen, redundante calls — die 'altijd afrekenen' onbetaalbaar duur maakt.
• •De meeste providers doen dit niet omdat hun oude infrastructuur de metering koppelt aan de upstream-call, niet aan de respons. Dat is een beperking van het factureringssysteem, verkleed als beleid.

Het gedrag dat we willen aanmoedigen

AI-agents zijn een nieuw soort API-client. Het zijn niet de zorgvuldige enterprise-integraties uit 2015 die één fout opvingen en een dienstdoende engineer mailden. Het zijn loops die, als er iets misgaat, even slapen en het opnieuw proberen — soms vijf of tien keer — en die het resultaat helemaal niet aan een mens tonen. Het hele punt van de loop is dat tijdelijke fouten onzichtbaar zijn voor de eindgebruiker.

Dat is een prima patroon. Het levert veerkrachtige producten op. Het verbergt de rommelige realiteit van het openbare internet voor gebruikers. Het probleem is dat het facturingsmodel van API's werd vastgelegd in een tijdperk waarin opnieuw proberen zeldzaam en duur genoeg was om het standaard te ontmoedigen. En zo werkt het nog steeds. Elke poging is een factureerbare call, ongeacht of ze iets teruggaf.

Concreet: een agent die een API met 99,5% uptime aanroept en tot vijf keer opnieuw probeert bij tijdelijke fouten, genereert tijdens die slechte 0,5% tot 5× de calls — en 5× de rekening. De agent deed het juiste. De klant betaalt voor de instabiliteit van de upstream.

Het eenvoudigere alternatief

Reken alleen af bij HTTP 200. Specifiek, alleen bij een geslaagde respons met de gedocumenteerde responsvorm. Al het andere — 4xx voor aanroeperfouten, 5xx voor onze fouten, timeouts, rate limits, gedeeltelijke-maar-misvormde responsen — is gratis.

Dit klinkt als een kleine verschuiving. Dat is het niet. Het verandert wat economisch rationeel is aan beide kanten:

• De provider heeft nu een directe financiële prikkel om instabiliteit op te lossen. Elke wispelturige 503 is een gemiste verkoop, geen gratis lunch. We hebben gemerkt dat het overstappen op alleen-bij-succes-facturering de grootste enkele kracht was die ons betrouwbaarheidswerk bovenaan de roadmap trok — er is geen spreadsheet-truc die downtime er goed uit laat zien als je de omzet van die calls prijsgeeft.
• De klant kan retry-budgetten agressief bemeten. Een loop met 5 pogingen en exponentiële backoff is een no-brainer wanneer het slechtste geval bij een tijdelijke fout één betaalde call is (het uiteindelijke succes) in plaats van zes (één betaald voor elke poging).
• De markt kan API's vergelijken op dollars-per-geslaagde-call in plaats van dollars-per-poging. Dat is de juiste eenheid. Als twee API's allebei '$0.001 per call' publiceren, maar de een 99,9% uptime heeft en de ander 95%, verschillen de voor de gebruiker zichtbare kosten 5× onder 'altijd afrekenen', en precies 0% onder 'alleen bij succes'. Welke een koper zou moeten verkiezen, is duidelijk — en 'alleen bij succes' maakt dat zichtbaar.

Wat er verandert aan hoe je agents bouwt

1. Retry-budgetten worden gratis

Onder 'altijd afrekenen'-facturering is het juiste retry-budget voor een handler van tijdelijke fouten ongeveer 1–2 pogingen — daarna begint de kost van herhaalde mislukkingen mee te tellen. Onder 'alleen bij succes' is het budget 'zolang de gebruiker kan wachten'. We zien routineus agent-loops met patronen van 5 pogingen, exponentiële backoff en jitter die roekeloos zouden zijn onder de oude facturering.

2. Optimistisch prefetchen wordt goedkoop

Een patroon dat onbetaalbaar duur is onder 'altijd afrekenen': speculatief een zoek-call afvuren terwijl de gebruiker nog aan het typen is, voor het geval de voorspelde query klopt. Als de voorspelling misgaat, gooi je het resultaat weg. Onder 'alleen bij succes' is dit goedkoop, want geannuleerde / ongebruikte calls geven succes terug maar je gooit de respons weg — dus je betaalt een kleine premie voor voorspelbaarheid en latency. Onder 'altijd afrekenen' is elke verkeerde voorspelling een betaalde call, wat de heuristiek te duur maakt om uit te brengen.

3. Redundante calls worden een betrouwbaarheidsinstrument

Soms is de goedkoopste betrouwbaarheidsstrategie om twee requests naar twee verschillende API's te vuren, degene te nemen die het eerst terugkomt, en de tragere weg te gooien. Onder 'altijd afrekenen' verdubbelt dat je rekening. Onder 'alleen bij succes' is het gratis voor de weggegooide call (je gebruikte de respons niet, je betaalde er niet voor). Ineens worden hedging-strategieën die dure abstracties waren, praktisch.

Wat 'succes' moet betekenen

Het model werkt alleen als 'succes' ondubbelzinnig is. We definiëren het strikt:

• HTTP 200 met het gedocumenteerde responsschema — factureerbaar.
• HTTP 200 met een fout verpakt in de responsbody — niet factureerbaar (dit zou de maas in de wet zijn die het hele model breekt).
• HTTP 4xx — niet factureerbaar. Dit omvat 401 (auth), 402 (onvoldoende credits), 422 (validatie), 404 (niet gevonden in sommige contexten).
• HTTP 5xx — niet factureerbaar.
• HTTP 429 (rate limit) — niet factureerbaar.
• Netwerkfouten / timeouts vóór onze edge — niet factureerbaar.

Voor batch-endpoints (bijv. URL Extract met 25 URL's in één call) is de call als geheel één HTTP 200 als er ook maar één URL geslaagd is, afgerekend tegen het per-URL-tarief. Het per-URL-veld status vertelt de aanroeper welke URL's mislukten. Het werk is gedaan; het is factureerbaar.

Waarom de meeste providers dit niet doen

Drie redenen, in volgorde van hoezeer elk telt:

• Factureringsinfrastructuur. Het standaardpatroon is meten bij de API-gateway, voordat de respons bekend is. De gateway zendt een factureerbaar event naar Kafka, het factureringssysteem aggregeert het, de rekening wordt verstuurd. De metering herbedraden zodat ze afgaat nadat de upstream-dienst met een statuscode heeft geantwoord, vereist ofwel (a) de gateway koppelen aan de gezondheid van de backend (wat nieuwe faalmodi creëert) ofwel (b) een reconciliatiepipeline schrijven die mislukte calls achteraf crediteert. Beide zijn echt engineeringwerk.
• Gewoonte. Het patroon werd gezet door betrouwbare backends — Twilio, AWS, Stripe. Het werkt prima wanneer je upstream 99,99% uptime heeft. API's die LLM's inpakken, het web scrapen of trage datapartners aanroepen, zijn veel minder betrouwbaar, maar het facturingspatroon werd overgeërfd uit het betrouwbare tijdperk en nooit bijgewerkt.
• Omzet. 'Altijd afrekenen' is gewoon meer geld. De meeste providers hebben niet op deze dimensie hoeven concurreren, omdat de meeste van hun klanten geen agent-verkeer zijn geweest, en synchrone menselijke gebruikers verdragen incidentele fouten beter dan het lezen van een facturingsmodel.

De eerste is echt engineering. De tweede en derde zijn traagheid. Beide zullen wijken naarmate agent-verkeer de meerderheid van het API-verbruik wordt — iets wat volgens de trendlijnen voor de meeste openbare API's binnen 18 maanden gebeurt.

Waar je als koper op moet letten

Als je data-API's evalueert voor een agent-workload, drie expliciete vragen:

• 'Rekenen jullie alleen bij HTTP 200 af, of bij elke factureerbare poging?' — een rechtstreeks antwoord is vereist. Accepteer geen 'meestal' of 'afhankelijk van het plan'.
• 'Hoe wordt HTTP 207 / gedeeltelijk succes afgerekend?' — dit legt het maas-in-de-wet-antwoord bloot.
• 'Wat is jullie gepubliceerde uptime, en wat is het SLA-terugbetalingsmechanisme als jullie die missen?' — 'alleen bij succes' is een sterk signaal, maar geen vervanging voor een echte SLA. Beide zouden aanwezig moeten zijn.

De verschuiving waar dit naar wijst

AI-agents veranderen de unit-economics van elke API die ze aanraken. API's die voor het agent-tijdperk zijn ontworpen, zien er anders uit — eenvoudigere vormen, voorspelbare schema's, machine-vriendelijke auth, transparante prijsstelling — en hun facturingsmodellen zien er ook anders uit. 'Alleen bij succes' is een van de eenvoudigere verschuivingen. De moeilijke, die nog voor ons ligt, is uitvogelen hoe multi-step agent-workflows over providers heen geprijsd worden wanneer geen enkele partij het volledige pad bezit.

Eis voorlopig 'alleen bij succes' van de providers waar je kunt. Bouw agents die er gebruik van maken. En als je een API gaat inkopen, reken het uit in dollars-per-geslaagde-call, niet in dollars-per-poging.

Geschreven door

Sarah Choy

CEO, API Pick

Sarah Choy is de CEO van API Pick. Ze schrijft over het bouwen van productieklare API's voor AI-agents en LLM-workflows.