AI-Agenten und geschlossene APIs: Dodo Pizza Fall

Wie KI-Agenten kommerzielle APIs neu definieren: Eine Fallstudie zur Integration mit Dodo Pizza ohne offene Schnittstelle

Das System ist als erweiterbarer Skill für Agent-Frameworks (Claude Code, Kimiclaw, Openclaw) konzipiert und kompatibel mit jeder Schnittstelle, die externe Tools unterstützt. Im Gegensatz zu Sprachassistenten, die auf informative Anfragen beschränkt sind, führt dieser Agent zustandsbehaftete Operationen aus: Verwaltung des Warenkorbs, Auswahl eines Abholpunkts, Zwei-Faktor-Authentifizierung über gespeicherte Cookies und Bestätigung der Zahlung vor Abbuchung der Mittel.

Ein entscheidendes Prinzip ist die Trennung der Verantwortlichkeiten:

• Agent-Schnittstelle — eine klare natürliche Sprachschnittstelle: „Bestelle eine Wurstpizza mit Limonade“, „Zeige die Historie der letzten drei Bestellungen“;
• Ausführungslogik — ein Node.js-Skript (dodo.mjs), das vom Agent-Runner ausgelöst wird;
• Netzwerkinteraktion — ausschließlich über headless Chromium (Puppeteer), das das Verhalten echter Nutzer nachahmt.

Der Agent parst kein HTML — er sendet fetch()-Anfragen an die interne API der Seite innerhalb des Kontexts der geladenen Seite, nachdem alle clientseitigen Prüfungen bestanden wurden. Für den Server sieht es wie regulärer Nutzertraffic aus: gleicher User-Agent, gleiche Cookies, gleiche navigator.webdriver === false, gleicher Ressourcenladeauftrag.

Reverse Engineering der geschlossenen API und Bekämpfung der Erkennung

Dokumentation für über 30 Endpunkte wurde durch Sniffen des Netzwerkverkehrs via Chrome DevTools Protocol gewonnen. Das Skript fängt alle fetch- und XHR-Anfragen mit /api/ während eines vollständigen Nutzerszenarios ab — vom Durchsuchen des Menüs bis zur finalen Auftragsbestätigung. Dadurch entstand eine vollständige Karte der Endpunkte: GET /api/v5/menu, POST /api/v5/cart/add, PUT /api/v5/order/confirm, GET /api/v5/profile/bonuses und mehr.

Wichtige technische Hürden und ihre Lösungen:

• Webdriver-Erkennung: ServicePipe prüft navigator.webdriver. Lösung: eine Zeile in den Puppeteer-Launch-Optionen — --disable-blink-features=AutomationControlled — plus manuelle Eigenschaftsersetzung zur Laufzeit.
• JS-Challenge: Die Seite zeigt unmittelbar nach page.goto() eine Captcha-Aufgabe an. Der Agent wartet, bis das Wort „Lieferung“ im <title> erscheint — ein Indikator für erfolgreiches SPA-Loading.
• reCAPTCHA v3 bei Login: Es gibt keine Softwarelösung. Die Autorisierung erfolgt manuell einmal auf einem GUI-fähigen Gerät; Cookies werden in einer Datei gespeichert und an den Server übertragen. Lebensdauer: 30 Tage; automatische Rotation ist nicht implementiert.
• Canvas/WebGL-Fingerprinting: Noch nicht aktiviert, aber die Architektur ermöglicht zukünftige Integration mit puppeteer-extra-plugin-stealth.

All diese Maßnahmen gewährleisten einen stabilen Betrieb über vier Monate ohne Ausfälle oder Blockierungen.

Vom Skill zur Agentenökonomie: Sichere Authentifizierung und Cross-Service-Orchestrierung

Derzeit arbeitet der Agent nach dem Modell „ein Nutzer — ein Konto — ein Dienst“. Ein skalierbares Modell erfordert jedoch eine standardisierte Agentenidentifikation. Es wird vorgeschlagen, Telekommunikationsanbieter als Identitätsprovider zu nutzen: MTS ID, Sber ID oder Tinkoff ID verifizieren bereits die Identität mittels Reisepass und SIM-Karte. Das OAuth-ähnliche Agent-Token-Schema:

• Der Nutzer authentifiziert sich einmal über den Telekommunikationsanbieter;
• Der Anbieter gibt ein JWT mit expliziten Scopes aus: orders:dodo:read, orders:dodo:write, limit:2000rub/day;
• Dodo überprüft die Token-Signatur und validiert den Scope vor Ausführung der Operation;
• Zugriffsrevokation erfolgt sofort über die mobile App des Anbieters.

Dies eliminiert die Notwendigkeit, Cookies zu speichern und manuelle Autorisierung durchzuführen, und gibt Unternehmen Kontrolle über Berechtigungen und Analysen.

Noch vielversprechender ist das Master-Agent-Modell. Es koordiniert mehrere Skills gleichzeitig:

Master-Agent:
├── Dodo Skill → Scharfe Wurst 25 cm — 369₽ (15-min Abholung)
├── Magnit Skill → Gute Cola 1,5L — 89₽ (30-min Lieferung)
└── Fazit: „Hole die Pizza bei Dodo ab, bestelle Cola bei Magnit.
Spare 66₽, bekommst dreimal so viel Cola. Okay?“

Ein solcher Agent nutzt das A2A (Agent-zu-Agent)-Protokoll: Jeder Dienst veröffentlicht eine maschinenlesbare Beschreibung seiner Fähigkeiten (z. B. im OpenAPI 3.1-Format mit der x-agent-capabilities-Erweiterung). Agenten entdecken sich gegenseitig dynamisch, ohne manuelle Integration.

Was wirklich zählt

• Agenten sind bereits in Produktion: Der Auftragsautor verwendet sie seit Dezember 2025 als primäre Methode, um Bestellungen aufzugeben — dies ist kein PoC, sondern eine funktionierende Lösung.
• Geschlossene APIs können legal über einen headless Browser genutzt werden, wenn das Verhalten echter Nutzer nachgeahmt wird und die Nutzungsbedingungen nicht verletzt werden (Automatisierung der eigenen Handlungen im eigenen Konto).
• Unternehmen verlieren Kontrolle und Analytik, wenn sie Agentenverkehr ignorieren: Aktuelle Integrationen sind in den Metriken nicht von Scrapern zu unterscheiden.
• Eine dedizierte agentenbereite API ist keine Option — sie ist ein Wettbewerbsvorteil: Sie senkt CAC auf null, eliminiert Marktplatzprovisionen und eröffnet einen Kanal für personalisierte Werbung.
• Personalisierung sollte auf der Clientseite liegen: Der Agent kennt die Bestellhistorie, das Budget und die Präferenzen — Unternehmen müssen lediglich eine saubere, dokumentierte API bereitstellen.

Implementierung: 380 Zeilen JavaScript, eine Abhängigkeit (puppeteer-core), Installation mit einem einzigen Befehl. Der Code wird aus ethischen Gründen nicht als Open Source veröffentlicht: Das Umgehen der Anti-Bot-Maßnahmen eines bestimmten Dienstes erfordert eine Vereinbarung mit dem API-Eigentümer. Ziel dieses Artikels ist es nicht, Anweisungen zum Umgehen zu geben, sondern den Dialog über die Standardisierung von Agentenschnittstellen anzustoßen.

— Editorial Team