Agentes de IA y APIs cerradas: caso Dodo Pizza

Cómo los agentes de IA están redefiniendo las APIs comerciales: un estudio de caso sobre la integración con Dodo Pizza sin una interfaz abierta

El sistema está diseñado como una habilidad extensible para marcos de agentes (Claude Code, Kimiclaw, Openclaw), compatible con cualquier interfaz que admita herramientas externas. A diferencia de los asistentes de voz, que se limitan a consultas informativas, este agente realiza operaciones estatales: gestionar el carrito de compras, seleccionar un punto de recogida, autenticación de dos factores mediante cookies guardadas y confirmar el pago antes de debitar los fondos.

Un principio crítico es la separación de responsabilidades:

• Interfaz del agente — una interfaz limpia en lenguaje natural: “pide una pizza de salchicha con limonada”, “muestra el historial de los últimos tres pedidos”;
• Lógica de ejecución — un script en Node.js (dodo.mjs) activado por el ejecutor del agente;
• Interacción de red — exclusivamente a través de Chromium sin cabeza (Puppeteer), imitando el comportamiento de un usuario real.

El agente no analiza HTML; realiza solicitudes fetch() a la API interna del sitio desde el contexto de la página cargada después de superar todas las verificaciones del lado cliente. Para el servidor, parece tráfico de usuario normal: mismo User-Agent, mismas cookies, mismo navigator.webdriver === false, mismo orden de carga de recursos.

Ingeniería inversa de la API cerrada y combate a la detección

Se obtuvo documentación de más de 30 endpoints al interceptar el tráfico de red mediante el Protocolo de DevTools de Chrome. El script intercepta todas las solicitudes fetch y XHR que contienen /api/ durante un escenario completo de usuario — desde la navegación por el menú hasta la finalización del pedido. Esto proporcionó un mapa completo de endpoints: GET /api/v5/menu, POST /api/v5/cart/add, PUT /api/v5/order/confirm, GET /api/v5/profile/bonuses, entre otros.

Obstáculos técnicos clave y sus soluciones:

• Detección de Webdriver: ServicePipe verifica navigator.webdriver. Solución: una línea en las opciones de lanzamiento de Puppeteer — --disable-blink-features=AutomationControlled — además de sustitución manual de propiedades en tiempo de ejecución.
• Desafío JS: el sitio muestra una tarea de captcha inmediatamente después de page.goto(). El agente espera a que aparezca la palabra “entrega” en el <title> — un indicador de carga exitosa de SPA.
• reCAPTCHA v3 al iniciar sesión: no existe solución software. La autorización se realiza manualmente una vez en una máquina con GUI; las cookies se guardan en un archivo y se transfieren al servidor. Vida útil: 30 días; no se implementa rotación automática.
• Huella digital de Canvas/WebGL: aún no se ha activado, pero la arquitectura permite futura integración con puppeteer-extra-plugin-stealth.

Todas estas medidas garantizan un funcionamiento estable durante cuatro meses sin fallos ni bloqueos.

De la habilidad a la economía de agentes: autenticación segura y orquestación multi-servicio

Actualmente, el agente opera bajo un modelo de “un usuario — una cuenta — un servicio”. Sin embargo, un modelo escalable requiere identificación estandarizada del agente. Se propone utilizar proveedores de telecomunicaciones como proveedores de identidad: MTS ID, Sber ID o Tinkoff ID ya verifican la identidad mediante pasaporte y tarjeta SIM. El esquema de token de agente similar a OAuth:

• El usuario se autentica una vez a través del proveedor de telecomunicaciones;
• El proveedor emite un JWT con ámbitos explícitos: orders:dodo:read, orders:dodo:write, limit:2000rub/day;
• Dodo verifica la firma del token y valida el ámbito antes de ejecutar la operación;
• La revocación de acceso es instantánea a través de la aplicación móvil del proveedor.

Esto elimina la necesidad de almacenar cookies y realizar autorizaciones manuales, otorgando a las empresas control sobre permisos y análisis.

Aún más prometedor es el modelo de agente maestro. Coordina múltiples habilidades simultáneamente:

Agente Maestro:
├── Habilidad Dodo → Salchicha picante 25 cm — 369₽ (recogida en 15 min)
├── Habilidad Magnit → Coca-Cola buena 1.5L — 89₽ (entrega en 30 min)
└── Conclusión: “Recoge la pizza de Dodo, pide cola de Magnit.
   Ahorra 66₽, obtén tres veces el volumen de cola. ¿Vale?”

Este tipo de agente utiliza el protocolo A2A (Agente a Agente): cada servicio publica una descripción legible por máquina de sus capacidades (por ejemplo, en formato OpenAPI 3.1 con la extensión x-agent-capabilities). Los agentes se descubren mutuamente de forma dinámica, sin integración manual.

Lo que importa

• Los agentes ya están en producción: el autor del pedido los ha estado utilizando como la principal forma de realizar pedidos desde diciembre de 2025 — esto no es un PoC, es una solución funcional.
• Las APIs cerradas pueden utilizarse legalmente mediante un navegador sin cabeza si se imita el comportamiento de un usuario real y no se violan los Términos de Servicio (automatizando las propias acciones en la propia cuenta).
• Las empresas pierden control y análisis cuando ignoran el tráfico de agentes: las integraciones actuales son indistinguibles de los scrapers en las métricas.
• Una API dedicada lista para agentes no es una opción — es una ventaja competitiva: reduce el CAC a cero, elimina comisiones del marketplace y abre un canal para promociones personalizadas.
• La personalización debe residir en el lado del cliente: el agente conoce el historial de pedidos, el presupuesto y las preferencias — las empresas solo necesitan proporcionar una API limpia y documentada.

Implementación: 380 líneas de JavaScript, una dependencia (puppeteer-core), instalación con un solo comando. El código no se publica como código abierto por razones éticas: eludir las medidas anti-bot de un servicio específico requiere acuerdo con el propietario de la API. El objetivo de este artículo no es proporcionar instrucciones sobre eludir medidas, sino invitar al diálogo sobre la estandarización de interfaces de agentes.

— Editorial Team