Por qué las APIs deberían cobrar solo al éxito — el caso de la facturación por HTTP 200
La mayoría de las APIs cobran cada llamada facturable. Los agentes de IA reintentan constantemente contra servicios upstream inestables — lo que significa que el modelo heredado de 'cobrar siempre' grava de hecho la resiliencia. Aquí va el caso de facturar solo al HTTP 200, y qué cambia en tu forma de diseñar agentes.
Resumen
- •Los agentes de IA reintentan, con razón, ante fallos transitorios (5xx, timeouts, límites de tasa). Bajo la facturación de 'cobrar siempre', cada reintento es un cargo real — convirtiendo un upstream con un 99,5% de uptime en una penalización de coste de 5× durante ese 0,5% malo.
- •'Cobrar solo al HTTP 200' alinea el incentivo del proveedor con el del cliente: los proveedores arreglan la inestabilidad, los clientes no la pagan.
- •También desbloquea patrones de diseño — presupuestos de reintento agresivos, prefetching optimista, llamadas redundantes — que 'cobrar siempre' vuelve prohibitivamente caros.
- •La mayoría de los proveedores no lo hacen porque su infraestructura heredada ata la medición a la llamada upstream, no a la respuesta. Eso es una limitación del sistema de facturación disfrazada de política.
El comportamiento que intentamos fomentar
Los agentes de IA son un nuevo tipo de cliente de API. No son las integraciones empresariales cuidadosas de 2015 que capturaban un error y enviaban un correo a un ingeniero de guardia. Son bucles que, cuando algo falla, duermen un rato y vuelven a intentarlo — a veces cinco o diez veces — y ni siquiera muestran el resultado a un humano. El sentido entero del bucle es que los fallos transitorios sean invisibles para el usuario final.
Es un gran patrón. Produce productos resilientes. Esconde a los usuarios la realidad caótica de la internet pública. El problema es que el modelo de facturación de las APIs se fijó en una era en la que reintentar era raro y lo bastante caro como para desincentivarlo por defecto. Y sigue funcionando así. Cada reintento es una llamada facturable, independientemente de si devolvió algo.
En concreto: un agente que golpea una API con un 99,5% de uptime y reintenta hasta cinco veces ante fallos transitorios generará, durante ese 0,5% malo, hasta 5× las llamadas — y 5× la factura. El agente hizo lo correcto. El cliente paga la inestabilidad del upstream.
La alternativa más simple
Cobra solo al HTTP 200. En concreto, solo ante una respuesta exitosa con la forma de respuesta documentada. Todo lo demás — 4xx por errores del llamante, 5xx por errores nuestros, timeouts, límites de tasa, respuestas parciales-pero-malformadas — es gratis.
Suena a un cambio pequeño. No lo es. Cambia lo que es económicamente racional para ambas partes:
- El proveedor tiene ahora un incentivo financiero directo para arreglar la inestabilidad. Cada 503 inestable es una venta perdida, no un almuerzo gratis. Hemos comprobado que adoptar la facturación solo al éxito fue la mayor fuerza individual que empujó nuestro trabajo de fiabilidad a la cima de la hoja de ruta — no hay truco de hoja de cálculo que haga que el downtime parezca bien cuando estás renunciando a los ingresos de esas llamadas.
- El cliente puede dimensionar presupuestos de reintento de forma agresiva. Un bucle de 5 reintentos con backoff exponencial es una obviedad cuando el peor caso para un fallo transitorio es una llamada pagada (el éxito final) en lugar de seis (una pagada por cada intento).
- El mercado puede comparar APIs por dólares-por-llamada-exitosa en lugar de dólares-por-intento. Esa es la unidad correcta. Si dos APIs publican ambas '$0.001 por llamada' pero una tiene un 99,9% de uptime y la otra un 95%, los costes visibles para el usuario difieren en 5× bajo 'cobrar siempre', y en exactamente un 0% bajo 'solo al éxito'. Cuál debería preferir un comprador es obvio — y 'solo al éxito' lo hace visible.
Qué cambia en tu forma de construir agentes
1. Los presupuestos de reintento se vuelven gratis
Bajo la facturación de 'cobrar siempre', el presupuesto de reintento correcto para un manejador de fallos transitorios es de aproximadamente 1–2 intentos — más allá de eso el coste de los fallos repetidos empieza a importar. Bajo 'solo al éxito', el presupuesto es 'tanto como el usuario pueda esperar'. Vemos rutinariamente bucles de agente con patrones de 5 reintentos, backoff exponencial y jitter que serían temerarios bajo la facturación heredada.
2. El prefetching optimista se vuelve barato
Un patrón prohibitivamente caro bajo 'cobrar siempre': lanzar una llamada de búsqueda especulativamente mientras el usuario todavía escribe, por si la query predicha acierta. Si la predicción falla, tiras el resultado. Bajo 'solo al éxito' esto es barato porque las llamadas canceladas / sin usar devuelven éxito pero descartas la respuesta — así pagas un pequeño plus por predictibilidad y latencia. Bajo 'cobrar siempre', cada predicción errónea es una llamada pagada, lo que hace la heurística demasiado cara como para sacarla.
3. Las llamadas redundantes se vuelven una herramienta de fiabilidad
A veces la estrategia de fiabilidad más barata es disparar dos peticiones a dos APIs distintas, quedarte con la que devuelva primero y descartar la más lenta. Bajo 'cobrar siempre' eso duplica tu factura. Bajo 'solo al éxito' es gratis para la llamada descartada (no usaste la respuesta, no la pagaste). De repente, estrategias de hedging que eran abstracciones caras se vuelven prácticas.
Qué tiene que significar 'éxito'
El modelo solo funciona si 'éxito' es inequívoco. Lo definimos de forma estricta:
- HTTP 200 con el esquema de respuesta documentado — facturable.
- HTTP 200 con un error envuelto en el body de la respuesta — no facturable (este sería el resquicio que rompe todo el modelo).
- HTTP 4xx — no facturable. Esto incluye 401 (auth), 402 (créditos insuficientes), 422 (validación), 404 (no encontrado en algunos contextos).
- HTTP 5xx — no facturable.
- HTTP 429 (límite de tasa) — no facturable.
- Errores de red / timeouts antes de nuestro edge — no facturables.
Para los endpoints en lote (p. ej. URL Extract con 25 URLs en una llamada), la llamada en su conjunto es un HTTP 200 si tuvo éxito alguna URL, facturada a la tarifa por URL. El campo status por URL le dice al llamante qué URLs fallaron. El trabajo se hizo; es facturable.
Por qué la mayoría de los proveedores no lo hacen
Tres razones, en orden de cuánto importa cada una:
- Infraestructura de facturación. El patrón estándar es medir en el API gateway, antes de conocer la respuesta. El gateway emite un evento facturable a Kafka, el sistema de facturación lo agrega, se envía la factura. Recablear la medición para que se dispare después de que el servicio upstream haya respondido con un código de estado requiere o bien (a) acoplar el gateway a la salud del backend (creando nuevos modos de fallo) o bien (b) escribir un pipeline de reconciliación que abone retroactivamente las llamadas fallidas. Ambos son trabajo de ingeniería real.
- Costumbre. El patrón lo fijaron backends fiables — Twilio, AWS, Stripe. Funciona bien cuando tu upstream tiene un 99,99% de uptime. Las APIs que envuelven LLMs, hacen scraping de la web o llaman a partners de datos lentos son mucho menos fiables, pero el patrón de facturación se heredó de la era fiable y nunca se actualizó.
- Ingresos. 'Cobrar siempre' es simplemente más dinero. La mayoría de los proveedores no han tenido que competir en esta dimensión porque la mayoría de sus clientes no han sido tráfico de agentes, y los usuarios humanos síncronos toleran mejor los fallos ocasionales que leerse un modelo de facturación.
La primera es ingeniería real. La segunda y la tercera son inercia. Ambas cederán a medida que el tráfico de agentes pase a ser la mayoría del consumo de APIs — algo que, según las líneas de tendencia, ocurrirá en los próximos 18 meses para la mayoría de las APIs públicas.
Qué buscar como comprador
Si estás evaluando APIs de datos para una carga de trabajo de agente, tres preguntas explícitas:
- '¿Cobráis solo al HTTP 200, o cada intento facturable?' — se exige una respuesta directa. No aceptes 'normalmente' ni 'según el plan'.
- '¿Cómo se factura el HTTP 207 / éxito parcial?' — saca a relucir la respuesta del resquicio.
- '¿Cuál es vuestro uptime publicado, y cuál es el mecanismo de reembolso del SLA si no lo cumplís?' — 'solo al éxito' es una señal fuerte pero no sustituye a un SLA real. Ambos deberían estar presentes.
El cambio al que apunta esto
Los agentes de IA cambian la economía unitaria de cada API que tocan. Las APIs diseñadas para la era de los agentes tienen otro aspecto — formas más simples, esquemas predecibles, auth machine-friendly, precios transparentes — y sus modelos de facturación también tienen otro aspecto. 'Solo al éxito' es uno de los cambios más simples. El difícil, que todavía tenemos por delante, es averiguar cómo fijar precios a los flujos de agente multipaso entre proveedores cuando ninguna parte es dueña del camino completo.
Por ahora, exige 'solo al éxito' a los proveedores donde puedas. Construye agentes que lo aprovechen. Y cuando vayas a comprar una API, echa las cuentas en dólares-por-llamada-exitosa, no en dólares-por-intento.
Preguntas frecuentes
¿No incentiva el 'solo al éxito' a que los proveedores clasifiquen los éxitos como fallos?
En teoría, pero la presión inversa es más fuerte: los desarrolladores comparan APIs por dólares-por-llamada-útil en el mundo real, y eso es exactamente lo que mide el 'solo al éxito'. Un proveedor que reclasificara en silencio éxitos como fallos se enfrentaría a una cola de soporte enfadada y a un rastro de reseñas públicas en cuestión de días. El mercado es lo bastante pequeño como para que esto se autocorrija.
¿Y si mi llamada tiene éxito parcial — por ejemplo, un extract en lote donde fallan 2 de 25 URLs?
Dos modelos razonables. (a) Toda la llamada es HTTP 200 si tuvo éxito alguna URL; los fallos por URL se reportan en el estado por URL. El trabajo se hizo, así que es facturable. (b) HTTP 207 (multi-status) para el parcial — cada URL se factura individualmente. Elegimos (a) porque hace los precios predecibles: los agentes saben que un HTTP 200 exitoso implica que el peor caso es el coste de créditos anunciado. (b) es más 'justo' pero más difícil de presupuestar.
¿Qué cuenta como fallo?
Nuestra regla: un HTTP 4xx que es claramente culpa del llamante (body malformado, falta de auth, créditos insuficientes) no se cobra. Un HTTP 5xx nunca se cobra — es problema nuestro. Los errores de red y los timeouts de nuestro lado nunca se cobran. Los límites de tasa (429) nunca se cobran. Lo único que se cobra es un HTTP 200 con la forma de respuesta anunciada.
¿Por qué la mayoría de los proveedores cobran cada llamada?
Tres razones, sobre todo históricas. (1) Los sistemas de facturación heredados miden en el API gateway, antes de conocer la respuesta. Conectar la facturación para que se dispare retroactivamente con el estado de la respuesta no es trivial. (2) El patrón lo fijaron Twilio y AWS en una era de backends fiables; las APIs que envuelven LLMs o hacen scraping de la web son mucho menos fiables, así que el supuesto deja de cumplirse. (3) Da más ingresos. Las dos primeras son excusas; la tercera es la verdad.
¿Hay casos donde 'cobrar siempre' tiene sentido?
Cuando la llamada consume genuinamente un coste fijo en cada invocación sin importar el resultado — por ejemplo, un call-out de hardware (SMS enviado), una mutación que es atómica en el límite (actualización de DNS), o un servicio cuyo backend no puede distinguir 'lo intentamos y fallamos' de 'lo hicimos y no te diste cuenta'. Para las APIs de datos de tipo lectura y las de búsqueda, el modelo no encaja.
APIs usadas en este artículo
Sarah Choy es la CEO de API Pick. Escribe sobre cómo construir APIs listas para producción para agentes de IA y flujos de trabajo con LLMs.