HTTP 402 por fin es real cómo el Monetization Gateway de Cloudflare deja que los agentes de IA paguen por request

El código 402 despertó después de 30 años dormido

¿Te acuerdas del HTTP 402 Payment Required que siempre aparecía en la spec como "reservado para uso futuro"? Pues el futuro ya llegó, devs. 🚀

Cloudflare soltó el Monetization Gateway en beta cerrado, permitiendo que los vendedores le cobren a agentes de IA por request, por búsqueda o por token — con liquidación on-chain en USDC sobre la red Base. Sin redirect a checkout. Sin API key. Solo una autorización firmada, embebida en la propia petición HTTP.

El problema que resuelve es directo: el modelo de suscripción no encaja con el tráfico de agentes. Un agente no quiere tu plan de $29 al mes. Quiere una búsqueda, un PDF, una inferencia — ahora, a las 3 de la mañana, sin nadie mirando.

Según el anuncio oficial de Cloudflare, el Gateway se encarga de todo: reglas de precio, settlement vía x402 Facilitator de Coinbase, retries, analytics y actualizaciones del protocolo. Tú te encargas del producto.

Si tienes una API, una MCP tool o un feed de datos que los agentes ya están golpeando, esto te cambia el modelo de negocio de la noche a la mañana. Y si quieres ver cómo las grandes empresas se están reorganizando para la IA autónoma, checa nuestro resumen del blueprint de SAP + Microsoft para la empresa autónoma.

Cómo funciona en la práctica (código primero)

En el fondo, el Gateway es un paywall para agentes. El flujo:

1. El agente pide un recurso sin pagar.
2. El servidor devuelve 402 Payment Required con el header payment-required que trae las instrucciones.
3. El agente firma una autorización (protocolo x402).
4. El pago liquida en Base con USDC.
5. Se entrega el recurso. ✅

Mira cómo se ve pegándole al AI Gateway de Cloudflare con inferencia pagada por request:

curl -iX POST "https://api.cloudflare.com/client/v4/accounts/$CLOUDFLARE_ACCOUNT_ID/ai/run" \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --header "Payment-Method: x402" \
  --header "Content-Type: application/json" \
  --data '{
    "model": "z-ai/glm-4.7-flash",
    "input": {
      "max_tokens": 9001,
      "messages": [
        { "role": "user", "content": "¿Qué es Cloudflare?" }
      ]
    }
  }'

Y aquí un agente pegándole a API2PDF sin API key — recibiendo el reto 402 de vuelta:

curl -iX POST https://v2.api2pdf.com/chrome/pdf/html \
  --header "Content-Type: application/json" \
  --data '{"html":"Hola desde un agente de IA"}'

# HTTP/2 402
# content-type: application/json
# payment-required: eyJ4NDAy...

Ese payment-required es un payload x402 en base64. El agente lo decodifica, firma la transacción, repite la petición y recibe el PDF. Sin registro. Sin tarjeta. Sin humano en medio.

El precio lo define el vendedor con matchers de request — patrones de URL, headers, query params — y soporta pricing fijo, variable y controlado por el origen (donde el propio motor de precios del vendedor responde dinámicamente).

Quién ya está corriendo en producción

• Cloudflare AI Gateway — inferencia pagada por request en todo el catálogo de modelos
• Ceramic.ai — índice de búsqueda con 40B+ páginas optimizado para llamadas de máquina (~50ms de respuesta)
• Stocktwits — señales por request: sentimiento, volumen, seguidores y trending de tickers
• API2PDF — renderizado de PDF con precio variable; quitó la fricción del registro y vio subir la conversión

El caso de API2PDF es el que tienes que estudiar si eres dev solo: reportaron >50% de caída en conversión cuando pedían tarjeta de crédito después del primer mes. El Gateway tumbó ese muro de tajo.

Limitaciones, cuidados y qué observar

Antes de salir a arrancar tu Stripe, unos puntos honestos:

El aviso crítico: esto es jugada de distribución, no de reemplazo de tu billing actual. Fíjate que Stocktwits mantuvo sus productos enterprise y licenciamiento intactos — encajaron el Gateway como canal nuevo para cliente nuevo. Ese es el patrón. No te canibalices tu base de suscripción; abre un carril para agentes que nunca iban a firmar nada de todas formas.

Otra cosa: el modelo de "pagar por contenido" (Pay Per Use) es explícitamente distinto al de por-request. Una página que se crawlea una vez y se usa mil veces necesita otra primitiva de precio. Cloudflare los trata como productos separados por una buena razón.

Y si estás manejando datos sensibles detrás de esos endpoints, la capa de pago es solo la mitad de la historia — todavía necesitas evitar fugas. Nuestro texto sobre prevenir fugas de datos en entornos de ML con SageMaker cubre la parte de seguridad que el HTTP 402 no toca.

Próximos pasos

Si eres vendedor:

1. Inscríbete al beta cerrado en el Dashboard de Cloudflare.
2. Elige un endpoint que los agentes ya golpean sin pagar — ese que hoy estás pagando tú.
3. Envuélvelo con una regla de precio fijo. Mide la conversión de 402 → pagado.
4. Solo después expande a pricing variable y controlado por el origen.

Si construyes agentes:

1. Aprende el handshake x402 — decodifica payment-required, firma, repite.
2. Presupuesta por tarea, no por mes. Tu agente decide cuánto gastar según lo que esté en juego.
3. Pon atención a las primitivas de identidad que Cloudflare dice que vienen — van a importar para confianza y rate-limiting.

Si solo estás observando: La señal real aquí no es Cloudflare. Es que el HTTP 402 está siendo tomado en serio por infraestructura a escala. Cuando un CDN grande se sube, los demás vienen atrás. Espera anuncios de competidores en 6–12 meses.

La economía agéntica necesita una vía de pago que encaje con cómo consumen los agentes. Esta es la primera creíble en producción. Vale tu atención. 👀

Lee también

• SAP + Microsoft en Sapphire 2026: el blueprint para la empresa autónoma con IA
• Alto a las fugas de datos en ML: blueprint de seguridad en 3 capas con SageMaker AI