Warum APIs nur bei Erfolg abrechnen sollten — das Argument für HTTP-200-Abrechnung
Die meisten APIs rechnen jeden abrechenbaren Aufruf ab. KI-Agenten versuchen bei wackeligen Upstream-Diensten ständig erneut — was heißt, dass das alte 'immer abrechnen'-Modell faktisch Resilienz besteuert. Hier ist das Argument für die Abrechnung nur bei HTTP 200, und was sich dadurch am Agentendesign ändert.
Auf einen Blick
- •KI-Agenten versuchen bei transienten Fehlern (5xx, Timeouts, Rate-Limits) vernünftigerweise erneut. Beim 'immer abrechnen'-Modell ist jeder Retry eine echte Belastung — was einen Upstream mit 99,5 % Uptime während der schlechten 0,5 % in einen 5×-Kostenaufschlag verwandelt.
- •'Nur bei HTTP 200 abrechnen' bringt das Interesse des Anbieters mit dem des Kunden in Einklang: Anbieter beheben Instabilität, Kunden zahlen nicht dafür.
- •Es schaltet zudem Designmuster frei — aggressive Retry-Budgets, optimistisches Prefetching, redundante Calls — die 'immer abrechnen' prohibitiv teuer macht.
- •Die meisten Anbieter tun das nicht, weil ihre Legacy-Infrastruktur das Metering an den Upstream-Call koppelt, nicht an die Response. Das ist eine Beschränkung des Abrechnungssystems, als Policy verkleidet.
Das Verhalten, das wir fördern wollen
KI-Agenten sind eine neue Art von API-Client. Sie sind nicht die sorgfältigen Enterprise-Integrationen von 2015, die einen Fehler abfingen und einem On-Call-Engineer eine E-Mail schickten. Sie sind Schleifen, die, wenn etwas scheitert, kurz schlafen und es erneut versuchen — manchmal fünf- oder zehnmal — und das Ergebnis gar nicht erst an einen Menschen weitergeben. Der ganze Sinn der Schleife ist, dass transiente Fehler für den Endnutzer unsichtbar sein sollen.
Das ist ein großartiges Muster. Es bringt resiliente Produkte hervor. Es verbirgt die chaotische Realität des öffentlichen Internets vor den Nutzern. Das Problem ist, dass das API-Abrechnungsmodell in einer Ära gesetzt wurde, in der Wiederholungen selten und teuer genug waren, um sie standardmäßig zu entmutigen. Es funktioniert noch immer so. Jeder Retry ist ein abrechenbarer Aufruf, unabhängig davon, ob er etwas zurückgegeben hat.
Konkret: Ein Agent, der eine API mit 99,5 % Uptime trifft und bei transienten Fehlern bis zu fünfmal erneut versucht, erzeugt während der schlechten 0,5 % bis zu 5× so viele Calls — und 5× die Rechnung. Der Agent hat das Richtige getan. Der Kunde zahlt für die Instabilität des Upstreams.
Die einfachere Alternative
Nur bei HTTP 200 abrechnen. Konkret nur bei einer erfolgreichen Response mit der dokumentierten Response-Form. Alles andere — 4xx bei Aufruferfehlern, 5xx bei unseren Fehlern, Timeouts, Rate-Limits, teilweise-aber-fehlerhafte Responses — ist kostenlos.
Das klingt nach einer kleinen Verschiebung. Ist es nicht. Es verändert, was auf beiden Seiten ökonomisch rational ist:
- Der Anbieter hat jetzt einen direkten finanziellen Anreiz, Instabilität zu beheben. Jeder wackelige 503 ist ein verpasster Verkauf, kein kostenloses Mittagessen. Wir haben festgestellt, dass die Einführung der Abrechnung nur bei Erfolg die einzelne stärkste Kraft war, die unsere Zuverlässigkeitsarbeit an die Spitze der Roadmap zog — es gibt keinen Tabellenkalkulationstrick, der Downtime gut aussehen lässt, wenn du den Umsatz aus diesen Calls verspielst.
- Der Kunde kann Retry-Budgets aggressiv dimensionieren. Eine 5-Retry-Exponential-Backoff-Schleife ist ein No-Brainer, wenn der schlimmste Fall bei einem transienten Fehler ein bezahlter Call (der eventuelle Erfolg) statt sechs ist (einer bezahlt pro Versuch).
- Der Markt kann APIs nach Dollar-pro-erfolgreichem-Call statt nach Dollar-pro-Versuch vergleichen. Das ist die richtige Einheit. Wenn zwei APIs beide '$0.001 pro Aufruf' angeben, aber eine bei 99,9 % Uptime und die andere bei 95 % liegt, unterscheiden sich die nutzersichtbaren Kosten beim 'immer abrechnen' um 5× und beim 'nur bei Erfolg' um exakt 0 %. Welche ein Käufer bevorzugen sollte, ist offensichtlich — und 'nur bei Erfolg' macht es sichtbar.
Was sich am Bau von Agenten ändert
1. Retry-Budgets werden kostenlos
Beim 'immer abrechnen'-Modell liegt das richtige Retry-Budget für einen Handler transienter Fehler bei etwa 1–2 Versuchen — darüber hinaus beginnen die Kosten wiederholter Fehlschläge zu zählen. Bei 'nur bei Erfolg' lautet das Budget 'so lange, wie der Nutzer warten kann'. Wir sehen routinemäßig Agentenschleifen mit 5-Retry-, Exponential-Backoff-, Jitter-Mustern, die unter Legacy-Abrechnung leichtsinnig wären.
2. Optimistisches Prefetching wird günstig
Ein Muster, das beim 'immer abrechnen' prohibitiv teuer ist: einen Such-Call spekulativ anstoßen, während der Nutzer noch tippt, falls die vorhergesagte Query stimmt. Liegt die Vorhersage daneben, das Ergebnis verwerfen. Bei 'nur bei Erfolg' ist das günstig, weil abgebrochene / ungenutzte Calls zwar Erfolg zurückgeben, du die Response aber verwirfst — du zahlst also einen kleinen Aufpreis für Vorhersagbarkeit und Latenz. Beim 'immer abrechnen' ist jede falsche Vorhersage ein bezahlter Call, was die Heuristik zu teuer macht, um sie auszuliefern.
3. Redundante Calls werden zum Zuverlässigkeitswerkzeug
Manchmal ist die günstigste Zuverlässigkeitsstrategie, zwei Requests an zwei verschiedene APIs abzufeuern, denjenigen zu nehmen, der zuerst zurückkommt, und den langsameren zu verwerfen. Beim 'immer abrechnen' verdoppelt das deine Rechnung. Bei 'nur bei Erfolg' ist es für den verworfenen Call kostenlos (du hast die Response nicht genutzt, du hast nicht dafür gezahlt). Plötzlich werden Hedging-Strategien, die teure Abstraktionen waren, praktikabel.
Was 'Erfolg' bedeuten muss
Das Modell funktioniert nur, wenn 'Erfolg' eindeutig ist. Wir definieren ihn eng:
- HTTP 200 mit dem dokumentierten Response-Schema — abrechenbar.
- HTTP 200 mit einem im Response-Body eingebetteten Fehler — nicht abrechenbar (das wäre das Schlupfloch, das das ganze Modell bricht).
- HTTP 4xx — nicht abrechenbar. Das umfasst 401 (Auth), 402 (unzureichende Credits), 422 (Validierung), 404 (in manchen Kontexten nicht gefunden).
- HTTP 5xx — nicht abrechenbar.
- HTTP 429 (Rate-Limit) — nicht abrechenbar.
- Netzwerkfehler / Timeouts vor unserem Edge — nicht abrechenbar.
Bei Batch-Endpoints (z. B. URL Extract mit 25 URLs in einem Call) ist der Call als Ganzes ein HTTP 200, sofern irgendeine URL erfolgreich war, abgerechnet zum Per-URL-Tarif. Das status-Feld je URL sagt dem Aufrufer, welche URLs scheiterten. Die Arbeit wurde getan; sie ist abrechenbar.
Warum die meisten Anbieter das nicht tun
Drei Gründe, in der Reihenfolge ihres Gewichts:
- Abrechnungsinfrastruktur. Das Standardmuster ist, am API-Gateway zu metern, bevor die Response bekannt ist. Das Gateway emittiert ein abrechenbares Event nach Kafka, das Abrechnungssystem aggregiert es, die Rechnung wird gesendet. Das Metering so umzuverdrahten, dass es nachdem der Upstream-Dienst mit einem Statuscode geantwortet hat, auslöst, erfordert entweder (a) eine Kopplung des Gateways an die Backend-Gesundheit (was neue Fehlermodi schafft) oder (b) das Schreiben einer Abgleich-Pipeline, die fehlgeschlagene Calls rückwirkend gutschreibt. Beides ist echte Engineering-Arbeit.
- Gewohnheit. Das Muster wurde von zuverlässigen Backends gesetzt — Twilio, AWS, Stripe. Es funktioniert prima, wenn dein Upstream bei 99,99 % Uptime liegt. APIs, die LLMs umhüllen, das Web scrapen oder langsame Datenpartner aufrufen, sind viel unzuverlässiger, doch das Abrechnungsmuster wurde aus der zuverlässigen Ära geerbt und nie aktualisiert.
- Umsatz. 'Immer abrechnen' ist schlicht mehr Geld. Die meisten Anbieter mussten in dieser Dimension nicht konkurrieren, weil die meisten Kunden kein Agenten-Traffic waren, und synchrone menschliche Nutzer tolerieren gelegentliche Fehler besser, als ein Abrechnungsmodell zu lesen.
Der erste ist echtes Engineering. Der zweite und dritte sind Trägheit. Beide werden nachgeben, wenn Agenten-Traffic zur Mehrheit des API-Konsums wird — was die Trendlinien zufolge für die meisten öffentlichen APIs binnen 18 Monaten geschieht.
Worauf man als Käufer achten sollte
Wenn du Daten-APIs für eine Agenten-Last evaluierst, drei explizite Fragen:
- 'Rechnet ihr nur bei HTTP 200 ab oder bei jedem abrechenbaren Versuch?' — klare Antwort erforderlich. Akzeptiere kein 'meistens' oder 'je nach Tarif'.
- 'Wie wird HTTP 207 / Teilerfolg abgerechnet?' — entlarvt die Schlupfloch-Antwort.
- 'Was ist eure veröffentlichte Uptime, und wie funktioniert die SLA-Rückerstattung, wenn ihr sie verfehlt?' — 'nur bei Erfolg' ist ein starkes Signal, aber kein Ersatz für ein echtes SLA. Beides sollte vorhanden sein.
Die Verschiebung, auf die das hindeutet
KI-Agenten verändern die Stückkostenrechnung jeder API, die sie berühren. APIs, die für die Agenten-Ära entworfen sind, sehen anders aus — einfachere Formen, vorhersagbare Schemata, maschinenfreundliche Auth, transparente Preise — und ihre Abrechnungsmodelle sehen ebenfalls anders aus. 'Nur bei Erfolg' ist eine der einfacheren Verschiebungen. Die schwierigere, noch vor uns liegende, ist herauszufinden, wie mehrstufige Agenten-Workflows über Anbieter hinweg bepreist werden, wenn keine einzelne Partei den gesamten Pfad besitzt.
Fürs Erste: Fordere 'nur bei Erfolg' bei den Anbietern ein, bei denen du es kannst. Bau Agenten, die das ausnutzen. Und wenn du eine API einkaufst, rechne mit Dollar-pro-erfolgreichem-Call, nicht mit Dollar-pro-Versuch.
Häufig gestellte Fragen
Verleitet 'nur bei Erfolg' Anbieter nicht dazu, Erfolge als Fehler fehlzuklassifizieren?
Theoretisch ja, aber der gegenläufige Druck ist stärker: Entwickler vergleichen APIs anhand realer Dollar-pro-nützlichem-Call, und genau das misst 'nur bei Erfolg'. Ein Anbieter, der heimlich Erfolge als Fehler umklassifiziert, hätte binnen Tagen eine wütende Support-Warteschlange und eine öffentliche Bewertungsspur. Der Markt ist klein genug, dass sich das selbst korrigiert.
Was, wenn mein Call teilweise erfolgreich ist — etwa ein Batch-Extract, bei dem 2 von 25 URLs scheitern?
Zwei sinnvolle Modelle. (a) Der ganze Call ist HTTP 200, wenn irgendeine URL erfolgreich war; Fehler je URL werden im Per-URL-Status gemeldet. Die Arbeit ist passiert, also ist sie abrechenbar. (b) HTTP 207 (Multi-Status) für Teilerfolg — jede URL wird einzeln abgerechnet. Wir haben (a) gewählt, weil es die Preise vorhersagbar macht: Agenten wissen, dass ein erfolgreiches HTTP 200 im schlimmsten Fall die angekündigten Credit-Kosten bedeutet. (b) ist 'fairer', aber schwerer zu budgetieren.
Was zählt als Fehler?
Unsere Regel: HTTP 4xx, das klar Schuld des Aufrufers ist (fehlerhafter Body, fehlende Auth, unzureichende Credits), wird nicht abgerechnet. HTTP 5xx wird nie abgerechnet — das ist unser Problem. Netzwerkfehler und Timeouts auf unserer Seite werden nie abgerechnet. Rate-Limits (429) werden nie abgerechnet. Das Einzige, was abgerechnet wird, ist HTTP 200 mit der angekündigten Response-Form.
Warum rechnen die meisten Anbieter jeden Aufruf ab?
Drei Gründe, meist historisch. (1) Legacy-Abrechnungssysteme metern am API-Gateway, bevor die Response bekannt ist. Die Abrechnung nachträglich an den Response-Status zu koppeln, ist nicht trivial. (2) Das Muster wurde von Twilio und AWS in einer Ära zuverlässiger Backends gesetzt; APIs, die LLMs umhüllen oder das Web scrapen, sind viel unzuverlässiger, also gilt die Annahme nicht mehr. (3) Es ist mehr Umsatz. Die ersten beiden sind Ausreden; der dritte ist die Wahrheit.
Gibt es Fälle, in denen 'immer abrechnen' sinnvoll ist?
Wenn der Call bei jeder Ausführung wirklich fixe Kosten verursacht, unabhängig vom Ergebnis — zum Beispiel ein Hardware-Auslöser (gesendete SMS), eine an der Grenze atomare Mutation (DNS-Update) oder ein Dienst, dessen Backend 'wir haben es versucht und sind gescheitert' nicht von 'wir haben es getan und du hast es nicht bemerkt' unterscheiden kann. Für lesende Daten-APIs und Such-APIs passt das Modell nicht.
APIs in diesem Artikel
Sarah Choy ist CEO von API Pick. Sie schreibt über produktionsreife APIs für KI-Agenten und LLM-Workflows.