Por que as APIs deveriam cobrar apenas no sucesso — o argumento a favor da cobrança por HTTP 200
A maioria das APIs cobra por toda chamada faturável. Os agentes de IA repetem chamadas constantemente contra serviços upstream instáveis — o que significa que o modelo legado de 'cobrar sempre' acaba tributando a resiliência. Veja o argumento a favor de faturar apenas no HTTP 200, e o que isso muda na forma de projetar agentes.
TL;DR
- •Os agentes de IA repetem chamadas, com razão, diante de falhas transitórias (5xx, timeouts, limites de taxa). Sob a cobrança de 'cobrar sempre', cada nova tentativa é uma cobrança real — transformando um upstream com 99,5% de uptime em uma penalidade de custo de 5× durante aquele 0,5% ruim.
- •'Cobrar apenas no HTTP 200' alinha o incentivo do provedor ao do cliente: os provedores corrigem a instabilidade, os clientes não a pagam.
- •Isso também desbloqueia padrões de projeto — orçamentos de retentativa agressivos, prefetching otimista, chamadas redundantes — que 'cobrar sempre' torna proibitivamente caros.
- •A maioria dos provedores não faz isso porque sua infraestrutura legada amarra a medição à chamada upstream, não à resposta. Isso é uma limitação do sistema de cobrança disfarçada de política.
O comportamento que estamos tentando incentivar
Os agentes de IA são um novo tipo de cliente de API. Não são as integrações corporativas cuidadosas de 2015 que capturavam um erro e enviavam um e-mail para um engenheiro de plantão. São loops que, quando algo falha, dormem um pouco e tentam de novo — às vezes cinco ou dez vezes — e nem sequer mostram o resultado a um humano. O objetivo inteiro do loop é que as falhas transitórias sejam invisíveis para o usuário final.
É um ótimo padrão. Produz produtos resilientes. Esconde dos usuários a realidade caótica da internet pública. O problema é que o modelo de cobrança das APIs foi estabelecido em uma era em que repetir era raro e caro o suficiente para ser desincentivado por padrão. E ele continua funcionando assim. Cada nova tentativa é uma chamada faturável, independentemente de ter retornado algo.
Concretamente: um agente que acessa uma API com 99,5% de uptime e repete até cinco vezes diante de falhas transitórias vai, durante aquele 0,5% ruim, gerar até 5× as chamadas — e 5× a conta. O agente fez a coisa certa. O cliente paga pela instabilidade do upstream.
A alternativa mais simples
Cobre apenas no HTTP 200. Especificamente, apenas em uma resposta bem-sucedida com o formato de resposta documentado. Todo o resto — 4xx por erros do chamador, 5xx por erros nossos, timeouts, limites de taxa, respostas parciais-mas-malformadas — é grátis.
Parece uma mudança pequena. Não é. Muda o que é economicamente racional para os dois lados:
- O provedor agora tem um incentivo financeiro direto para corrigir a instabilidade. Cada 503 instável é uma venda perdida, não almoço grátis. Descobrimos que adotar a cobrança apenas no sucesso foi a maior força individual que empurrou nosso trabalho de confiabilidade para o topo do roadmap — não existe truque de planilha que faça o downtime parecer aceitável quando você está abrindo mão da receita dessas chamadas.
- O cliente pode dimensionar orçamentos de retentativa de forma agressiva. Um loop de 5 tentativas com backoff exponencial é óbvio quando o pior caso para uma falha transitória é uma chamada paga (o sucesso final) em vez de seis (uma paga por tentativa).
- O mercado pode comparar APIs por dólares-por-chamada-bem-sucedida em vez de dólares-por-tentativa. Essa é a unidade certa. Se duas APIs ambas publicam '$0.001 por chamada' mas uma tem 99,9% de uptime e a outra 95%, os custos visíveis para o usuário diferem em 5× sob 'cobrar sempre', e em exatamente 0% sob 'apenas no sucesso'. Qual delas um comprador deveria preferir é óbvio — e o 'apenas no sucesso' torna isso visível.
O que muda na forma de construir agentes
1. Os orçamentos de retentativa ficam grátis
Sob a cobrança de 'cobrar sempre', o orçamento de retentativa correto para um handler de falhas transitórias é de cerca de 1–2 tentativas — além disso, o custo das falhas repetidas começa a importar. Sob 'apenas no sucesso', o orçamento é 'o quanto o usuário puder esperar'. Vemos rotineiramente loops de agente com padrões de 5 tentativas, backoff exponencial e jitter que seriam imprudentes sob a cobrança legada.
2. O prefetching otimista fica barato
Um padrão proibitivamente caro sob 'cobrar sempre': disparar uma chamada de busca especulativamente enquanto o usuário ainda está digitando, caso a query prevista esteja certa. Se a previsão estiver errada, você joga o resultado fora. Sob 'apenas no sucesso' isso é barato porque chamadas canceladas / não utilizadas retornam sucesso mas você descarta a resposta — então você paga um pequeno prêmio por previsibilidade e latência. Sob 'cobrar sempre', cada previsão errada é uma chamada paga, o que torna a heurística cara demais para colocar em produção.
3. As chamadas redundantes viram uma ferramenta de confiabilidade
Às vezes a estratégia de confiabilidade mais barata é disparar duas requisições para duas APIs diferentes, ficar com a que responder primeiro e descartar a mais lenta. Sob 'cobrar sempre' isso dobra a sua conta. Sob 'apenas no sucesso' é grátis para a chamada descartada (você não usou a resposta, você não a pagou). De repente, estratégias de hedging que eram abstrações caras se tornam práticas.
O que 'sucesso' precisa significar
O modelo só funciona se 'sucesso' for inequívoco. Nós o definimos de forma estrita:
- HTTP 200 com o schema de resposta documentado — faturável.
- HTTP 200 com um erro embrulhado no body da resposta — não faturável (essa seria a brecha que quebra o modelo inteiro).
- HTTP 4xx — não faturável. Isso inclui 401 (auth), 402 (créditos insuficientes), 422 (validação), 404 (não encontrado em alguns contextos).
- HTTP 5xx — não faturável.
- HTTP 429 (limite de taxa) — não faturável.
- Erros de rede / timeouts antes do nosso edge — não faturáveis.
Para endpoints em lote (por ex. URL Extract com 25 URLs em uma chamada), a chamada como um todo é um HTTP 200 se qualquer URL teve sucesso, cobrada à taxa por URL. O campo status por URL diz ao chamador quais URLs falharam. O trabalho foi feito; é faturável.
Por que a maioria dos provedores não faz isso
Três razões, na ordem de quanto cada uma importa:
- Infraestrutura de cobrança. O padrão usual é medir no API gateway, antes de a resposta ser conhecida. O gateway emite um evento faturável para o Kafka, o sistema de cobrança o agrega, a conta é enviada. Recablear a medição para disparar depois de o serviço upstream ter respondido com um código de status exige ou (a) acoplar o gateway à saúde do backend (criando novos modos de falha) ou (b) escrever um pipeline de reconciliação que credite retroativamente as chamadas falhadas. Ambos são trabalho de engenharia real.
- Hábito. O padrão foi estabelecido por backends confiáveis — Twilio, AWS, Stripe. Funciona bem quando o seu upstream tem 99,99% de uptime. As APIs que encapsulam LLMs, fazem scraping da web ou chamam parceiros de dados lentos são muito menos confiáveis, mas o padrão de cobrança foi herdado da era confiável e nunca foi atualizado.
- Receita. 'Cobrar sempre' é simplesmente mais dinheiro. A maioria dos provedores não precisou competir nessa dimensão porque a maioria de seus clientes não era tráfego de agentes, e os usuários humanos síncronos toleram falhas ocasionais melhor do que toleram ler um modelo de cobrança.
A primeira é engenharia real. A segunda e a terceira são inércia. Ambas vão ceder à medida que o tráfego de agentes se tornar a maioria do consumo de APIs — algo que, segundo as linhas de tendência, vai acontecer nos próximos 18 meses para a maioria das APIs públicas.
O que procurar como comprador
Se você está avaliando APIs de dados para uma carga de trabalho de agente, três perguntas explícitas:
- 'Vocês cobram apenas no HTTP 200, ou em cada tentativa faturável?' — resposta direta exigida. Não aceite 'normalmente' nem 'depende do plano'.
- 'Como o HTTP 207 / sucesso parcial é cobrado?' — expõe a resposta da brecha.
- 'Qual é o uptime que vocês publicam, e qual é o mecanismo de reembolso do SLA se vocês não o atingirem?' — 'apenas no sucesso' é um sinal forte, mas não substitui um SLA de verdade. Ambos deveriam estar presentes.
A mudança para a qual isso aponta
Os agentes de IA mudam a economia unitária de cada API em que tocam. As APIs projetadas para a era dos agentes têm outra cara — formatos mais simples, schemas previsíveis, auth amigável para máquinas, precificação transparente — e seus modelos de cobrança também têm outra cara. 'Apenas no sucesso' é uma das mudanças mais simples. A difícil, que ainda está à nossa frente, é descobrir como precificar fluxos de agente de múltiplas etapas entre provedores quando nenhuma parte isolada é dona do caminho completo.
Por enquanto, exija 'apenas no sucesso' dos provedores onde você puder. Construa agentes que tirem proveito disso. E quando for comprar uma API, faça as contas em dólares-por-chamada-bem-sucedida, não em dólares-por-tentativa.
Perguntas Frequentes
O 'apenas no sucesso' não incentiva os provedores a classificarem sucessos como falhas?
Na teoria, sim, mas a pressão inversa é mais forte: os desenvolvedores comparam APIs por dólares-por-chamada-útil no mundo real, e é exatamente isso que o 'apenas no sucesso' mede. Um provedor que reclassificasse silenciosamente sucessos como falhas enfrentaria uma fila de suporte irritada e um rastro de avaliações públicas em questão de dias. O mercado é pequeno o suficiente para que isso se autocorrija.
E se a minha chamada tiver sucesso parcial — por exemplo, um extract em lote em que 2 de 25 URLs falham?
Dois modelos razoáveis. (a) A chamada inteira é HTTP 200 se qualquer URL teve sucesso; as falhas por URL são reportadas no status por URL. O trabalho aconteceu, então é faturável. (b) HTTP 207 (multi-status) para o parcial — cada URL é faturada individualmente. Escolhemos (a) porque torna a precificação previsível: os agentes sabem que um HTTP 200 bem-sucedido significa que o pior caso é o custo de créditos anunciado. (b) é mais 'justo', mas mais difícil de orçar.
O que conta como falha?
Nossa regra: um HTTP 4xx que é claramente culpa do chamador (body malformado, falta de auth, créditos insuficientes) não é cobrado. Um HTTP 5xx nunca é cobrado — é problema nosso. Erros de rede e timeouts do nosso lado nunca são cobrados. Limites de taxa (429) nunca são cobrados. A única coisa cobrada é um HTTP 200 com o formato de resposta anunciado.
Por que a maioria dos provedores cobra por toda chamada?
Três razões, em sua maioria históricas. (1) Os sistemas de cobrança legados medem no API gateway, antes de a resposta ser conhecida. Conectar a cobrança para disparar retroativamente com base no status da resposta não é trivial. (2) O padrão foi estabelecido pela Twilio e pela AWS em uma era de backends confiáveis; as APIs que encapsulam LLMs ou fazem scraping da web são muito menos confiáveis, então a premissa deixa de valer. (3) Gera mais receita. As duas primeiras são desculpas; a terceira é a verdade.
Existem casos em que 'cobrar sempre' faz sentido?
Quando a chamada realmente consome um custo fixo a cada invocação, independentemente do resultado — por exemplo, um acionamento de hardware (SMS enviado), uma mutação que é atômica na fronteira (atualização de DNS), ou um serviço cujo backend não consegue distinguir 'tentamos e falhamos' de 'fizemos e você não percebeu'. Para APIs de dados do tipo leitura e APIs de busca, o modelo não se encaixa.
APIs usadas neste artigo
Sarah Choy é a CEO da API Pick. Ela escreve sobre a construção de APIs prontas para produção para agentes de IA e fluxos de trabalho com LLMs.