AI-agenty přetvářejí komerční API: případ integrace s Dodo Pizza bez veřejného rozhraní
AI-agenty již nejsou pouhým konceptem — v produkci provádějí transakční operace: přidávají zboží do košíku, kontrolují bonusový zůstatek, potvrzují platbu a vyřizují objednávky. Klíčový technický výzva spočívá v interakci se službami, které neposkytují veřejná API. Případ integrace s Dodo Pizza ukazuje, jak vývojář implementoval plně funkční agentní skill nad uzavřeným RESTful rozhraním, obešel WAF a antibotovou ochranu pomocí headless prohlížeče a zároveň zachoval striktní soukromí dat a dodržení podmínek uživatelské smlouvy.
Architektura agenta: od CLI po kontextový skill
Systém je postaven jako rozšiřitelný skill pro agentní frameworky (Claude Code, Kimiclaw, Openclaw), kompatibilní s jakýmkoli rozhraním podporujícím externí nástroje. Na rozdíl od hlasových asistentů, které jsou omezeny pouze na informační dotazy, tento agent provádí stateful operace: správu košíku, výběr místa osobního vyzvednutí, dvoufaktorovou autorizaci prostřednictvím uložených cookies a potvrzení platby před stržením peněz.
Kriticky důležitý je princip rozdělení odpovědnosti:
- Agentovo rozhraní — čisté rozhraní v přirozeném jazyce: „objednej si pizzu s salámami a limonádou“, „ukázka historie posledních tří objednávek“;
- Provozní logika — Node.js skript (
dodo.mjs), spouštěný na základě triggeru z agentního runneru; - Síťová interakce — výhradně prostřednictvím headless Chromium (Puppeteer), imitujícího chování reálného uživatele.
Agent neparsuje HTML — provádí fetch()-požadavky na interní API webu z kontextu načtené stránky po absolvování všech klientských kontrol. Pro server je to obvyklý uživatelský provoz: stejný User-Agent, stejné cookies, stejný navigator.webdriver === false, stejný sled načítání zdrojů.
Reverse engineering uzavřeného API a boj proti detekci
Dokumentace k více než 30 endpointů byla získána metodou sniffingu síťového provozu prostřednictvím Chrome DevTools Protocol. Skript zachycuje všechny fetch a XHR-požadavky obsahující /api/ během celého uživatelského scénáře — od prohlédnutí menu až po finalizaci objednávky. Tím byla získána kompletní mapa endpointů: GET /api/v5/menu, POST /api/v5/cart/add, PUT /api/v5/order/confirm, GET /api/v5/profile/bonuses a další.
Hlavní technické překážky a jejich řešení:
- Detekce Webdriver: ServicePipe kontroluje
navigator.webdriver. Řešení — jedna řádka v nastavení Puppeteer launch options:--disable-blink-features=AutomationControlled, plus ruční úprava vlastnosti runtime. - JS-challenge: web zobrazí captcha úlohu ihned po
page.goto(). Agent čeká na objevení se řádku „doručení“ v<title>— indikátor úspěšného načtení SPA. - reCAPTCHA v3 při přihlášení: programové řešení chybí. Autorizace probíhá jednou ručně na stroji s GUI, cookies se uloží do souboru a přenesou se na server. Životnost — 30 dní, automatický rotace není realizována.
- Canvas/WebGL fingerprinting: zatím není aktivováno, ale architektura počítá s budoucí integrací s
puppeteer-extra-plugin-stealth.
Všechny tyto opatření zajišťují stabilní provoz po dobu 4 měsíců bez poruch a blokací.
Od skillu k agentní ekonomice: bezpečná autorizace a mezi-servisní orchestrace
Nyní agent pracuje v režimu „jeden uživatel — jeden účet — jeden servis“. Ale škálovatelný model vyžaduje standardizovanou agentní identifikaci. Navrhuje se využít telekomunikačních providerů jako identity provider: MTS ID, Sber ID nebo Tinkoff ID již ověřují totožnost prostřednictvím pasu a SIM. Schéma OAuth-podobného agentního tokenu:
- Uživatel se jednou autorizuje přes telekomunikace;
- Telekom dává JWT s explicitními scope’y:
orders:dodo:read,orders:dodo:write,limit:2000rub/day; - Dodo kontroluje podpis tokenu a validuje scope před provedením operace;
- Odmítnutí přístupu — okamžité prostřednictvím mobilní aplikace providera.
Toto eliminuje nutnost ukládání cookies a ruční autorizace, dává byznysu kontrolu nad právy a analytiku.
Ještě perspektivnější je model master-agenta. Ten koordinuje několik skillů paralelně:
Master Agent:
├── Dodo Skill → Pikantní salámky 25 cm — 369₽ (samovyzvednutí za 15 min)
├── Magnit Skill → Dobrá Cola 1,5 l — 89₽ (doručení za 30 min)
└── Závěr: „Vezmi pizzu z Dodo, objednej colu z Magnitu.
Úspora 66₽, objem coly 3x větší. Ok?"
Takový agent využívá protokol A2A (Agent-to-Agent): každý servis publikuje strojově čitelný popis svých možností (například ve formátu OpenAPI 3.1 s extension x-agent-capabilities). Agenti navzájem detekují jeden druhého dynamicky, bez ruční integrace.
Co je důležité
- Agenti již pracují v produkci: autor objednávky ho používá jako hlavní způsob vyřizování objednávek od prosince 2025 — to není PoC, ale funkční řešení.
- Uzavřená API lze legálně využívat prostřednictvím headless prohlížeče, pokud se imituje chování reálného uživatele a nedochází k porušení ToS (automatizace vlastních akcí v vlastním účtu).
- Byznys ztrácí kontrolu a analytiku, ignoruje agentní provoz: aktuální integrace jsou v metrikách k nerozeznání od scraperů.
- Vyhrazené agent-ready API není volbou, ale konkurenční výhodou: snižuje CAC na nulu, odstraňuje provize marketplace a otevírá kanál pro personalizované promo.
- Personalizace by měla žít na straně klienta: agent zná historii objednávek, rozpočet a preference — byznysu stačí poskytnout čisté, dokumentované API.
Realizace — 380 řádků JavaScriptu, jedna závislost (puppeteer-core), instalace jediným příkazem. Kód se nezveřejňuje v open source z etických důvodů: obcházení antibotu konkrétního servisu vyžaduje souhlas s majitelem API. Cíl článku není návod na obcházení, ale pozvání k dialogu o standardizaci agentních rozhraní.
— Editorial Team
Zatím žádné komentáře.