How AI Agents Are Redefining Commercial APIs: A Case Study on Integrating with Dodo Pizza Without an Open Interface
AI agents are no longer just a concept—they’re already handling transactional tasks in production: adding items to the cart, checking bonus balances, confirming payments, and placing orders. The key technical challenge is interacting with services that don’t offer public APIs. This case study with Dodo Pizza demonstrates how a developer built a fully functional agent skill on top of a closed RESTful interface, bypassing WAFs and anti-bot protections using a headless browser while maintaining strict data privacy and compliance with Terms of Service.
Agent Architecture: From CLI to Contextual Skill
The system is designed as an extensible skill for agent frameworks (Claude Code, Kimiclaw, Openclaw), compatible with any interface that supports external tools. Unlike voice assistants, which are limited to informational queries, this agent performs stateful operations: managing the shopping cart, selecting a pickup point, two-factor authentication via saved cookies, and confirming payment before funds are debited.
A critical principle is the separation of responsibilities:
- Agent Interface — a clean natural language interface: “order a sausage pizza with lemonade,” “show the history of the last three orders”;
- Execution Logic — a Node.js script (
dodo.mjs) triggered by the agent runner; - Network Interaction — exclusively through headless Chromium (Puppeteer), mimicking real-user behavior.
The agent doesn’t parse HTML—it makes fetch() requests to the site’s internal API from within the context of the loaded page after passing all client-side checks. To the server, it looks like regular user traffic: same User-Agent, same cookies, same navigator.webdriver === false, same resource-loading order.
Reverse Engineering the Closed API and Fighting Detection
Documentation for over 30 endpoints was obtained by sniffing network traffic via Chrome DevTools Protocol. The script intercepts all fetch and XHR requests containing /api/ during a full user scenario—from browsing the menu to finalizing the order. This provided a complete map of endpoints: GET /api/v5/menu, POST /api/v5/cart/add, PUT /api/v5/order/confirm, GET /api/v5/profile/bonuses, and more.
Key technical hurdles and their solutions:
- Webdriver detection: ServicePipe checks
navigator.webdriver. Solution: one line in Puppeteer launch options—--disable-blink-features=AutomationControlled—plus manual property substitution at runtime. - JS-challenge: The site displays a captcha task immediately after
page.goto(). The agent waits for the word “delivery” to appear in the<title>—an indicator of successful SPA loading. - reCAPTCHA v3 upon login: No software solution exists. Authorization is performed manually once on a GUI-enabled machine; cookies are saved to a file and transferred to the server. Lifespan: 30 days; automatic rotation isn’t implemented.
- Canvas/WebGL fingerprinting: Not yet activated, but the architecture allows for future integration with
puppeteer-extra-plugin-stealth.
All these measures ensure stable operation for four months without failures or blocks.
From Skill to Agent Economy: Secure Authentication and Cross-Service Orchestration
Currently, the agent operates on a “one user—one account—one service” model. However, a scalable model requires standardized agent identification. It’s proposed to use telecom providers as identity providers: MTS ID, Sber ID, or Tinkoff ID already verify identity via passport and SIM card. The OAuth-like agent token scheme:
- The user authenticates once through the telecom provider;
- The telecom issues a JWT with explicit scopes:
orders:dodo:read,orders:dodo:write,limit:2000rub/day; - Dodo verifies the token signature and validates the scope before executing the operation;
- Access revocation is instantaneous via the provider’s mobile app.
This eliminates the need to store cookies and perform manual authorization, giving businesses control over permissions and analytics.
Even more promising is the master-agent model. It coordinates multiple skills simultaneously:
Master Agent:
├── Dodo Skill → Spicy Sausage 25 cm — 369₽ (15-min pickup)
├── Magnit Skill → Good Cola 1.5L — 89₽ (30-min delivery)
└── Conclusion: “Pick up the pizza from Dodo, order cola from Magnit.
Save 66₽, get three times the cola volume. Okay?”Such an agent uses the A2A (Agent-to-Agent) protocol: each service publishes a machine-readable description of its capabilities (e.g., in OpenAPI 3.1 format with the x-agent-capabilities extension). Agents discover each other dynamically, without manual integration.
What Matters
- Agents are already in production: the order author has been using them as the primary way to place orders since December 2025—this isn’t a PoC, it’s a working solution.
- Closed APIs can be used legally via a headless browser if real-user behavior is mimicked and the Terms of Service aren’t violated (automating one’s own actions in one’s own account).
- Businesses lose control and analytics when they ignore agent traffic: current integrations are indistinguishable from scrapers in metrics.
- A dedicated agent-ready API isn’t an option—it’s a competitive advantage: it reduces CAC to zero, eliminates marketplace commissions, and opens a channel for personalized promotions.
- Personalization should reside on the client side: the agent knows the order history, budget, and preferences—businesses only need to provide a clean, documented API.
Implementation: 380 lines of JavaScript, one dependency (puppeteer-core), installation with a single command. The code isn’t published as open source for ethical reasons: bypassing a specific service’s anti-bot measures requires agreement with the API owner. The goal of this article isn’t to provide instructions on circumvention, but to invite dialogue about standardizing agent interfaces.
— Editorial Team
No comments yet.