Integuru v0: Integrationen aus HAR-Dateien statt aus offiziellen APIs

Welche Lücke Integuru v0 schließt

Viele Plattformen bieten für genau die Aktion, die ein Team automatisieren möchte, keinen dokumentierten Endpunkt. Die Weboberfläche kann es trotzdem. Integuru v0 setzt an dieser Stelle an und richtet sich an Entwickler, die eine solche Aktion wiederholbar ausführen wollen, ohne die Oberfläche zu bedienen. Der Ablauf laut README: mit create_har.py einen Browser starten, sich anmelden, die gewünschte Aktion ausführen, und der Agent erhält daraus einen Netzwerkmitschnitt, eine Datei mit den Cookies und einen Prompt, der die Aktion beschreibt. Das Ergebnis ist ausführbarer Python-Code, der die internen Endpunkte direkt anspricht. Der Anspruch ist ausdrücklich auf Plattformen ohne offizielle API begrenzt. Wer eine dokumentierte Schnittstelle hat, sollte sie nutzen; der Ansatz ist ein Umweg, kein Ersatz.

Vom HAR-Mitschnitt zum Abhängigkeitsgraphen

Der Mechanismus ist im README in fünf Schritten beschrieben. Zuerst identifiziert der Agent die Anfrage, die die gewünschte Wirkung auslöst. Im Beispiel ist das ein Download von Utility Bills über eine URL, die accountId und userId als Query-Parameter trägt. Diese Parameter sind dynamisch und stammen aus anderen Anfragen. Der Agent sucht die Anfragen, die sie liefern, und hängt die Download-Anfrage davon ab. Das wiederholt sich, bis eine Anfrage nur noch von den Authentifizierungs-Cookies abhängt. So entsteht ein gerichteter Graph, dessen Wurzel die Zielanfrage ist. Die Codegenerierung läuft dann rückwärts: Der Agent beginnt bei den Knoten ohne ausgehende Kanten und wandelt jeden Knoten in eine Funktion um, bis er den Master-Knoten erreicht. Bemerkenswert ist die Reihenfolge. Nicht der Ablauf wird aus dem Mitschnitt abgelesen, sondern die Abhängigkeiten werden rekonstruiert und daraus der Ablauf erzeugt.

Installation und die tatsächlichen Aufrufe

Der Einstieg verlangt eine Umgebungsvariable OPENAI_API_KEY und ein Modell, das laut README mindestens so leistungsfähig wie o1-mini sein sollte, idealerweise auf dem Niveau von o1-preview. Die Installation läuft über Poetry: poetry install, danach poetry shell, dann poetry run ipython kernel install --user --name=integuru für die Jupyter-Nutzung. Der Browser wird mit poetry run python create_har.py gestartet. Der eigentliche Lauf ist ein einziger Befehl, poetry run integuru --prompt "download utility bills" --model gpt-4o. Alternativ gibt es main.ipynb. Die CLI kennt --har-path (Standard ./network_requests.har), --cookie-path (Standard ./cookies.json), --max_steps mit Default 20, --input_variables im Format key value und --generate-code. Ohne --generate-code entsteht nur der Graph. --input_variables wirkt laut README derzeit ausschließlich auf die Graphgenerierung, nicht auf die Codegenerierung. Tests laufen mit poetry run pytest, die CI-Datei liegt unter .github/workflows/ci.yml und setzt Python 3.12 voraus.

Modellwahl ist keine Nebensache

Das README empfiehlt für die Graphgenerierung gpt-4o, weil es Function Calling unterstützt. Für die Codegenerierung wechselt Integuru automatisch zu o1-preview, sofern das im OpenAI-Konto verfügbar ist. Das ist eine harte Kopplung an einen Anbieter und an dessen Modellkatalog. Wer kein OpenAI-Konto mit Zugriff auf diese Modelle hat, kann den Agenten nicht betreiben. Die Qualität des erzeugten Graphen hängt damit unmittelbar von einem externen, versionierten Dienst ab. Ändert der Anbieter Modelle oder Preise, ändert sich das Verhalten des Werkzeugs, ohne dass sich im Repository etwas tut.

Grenzen, die im README stehen und solche, die es nicht tut

Die auffälligste Einschränkung ist der Umfang: Dieses Repository enthält laut eigener Beschreibung die früheste öffentlich freigegebene Version des Agenten. Die aktuelle Version liegt unter integuru.com. Wer hier einsteigt, arbeitet bewusst mit einem eingefrorenen Stand. Dazu kommen die explizit genannten Grenzen: --input_variables wirkt nur auf die Graphgenerierung, und der Lauf ist auf --max_steps 20 begrenzt. Reicht das nicht, bricht der Agent ab, statt weiter zu suchen. Ein weiterer Punkt ist die Authentifizierung. Das README behandelt 2FA nur als Hinweis: Man soll den 2FA-Prozess abschließen und die Cookies beziehungsweise Session-Tokens danach verwenden. Der erzeugte Code erbt damit die Lebensdauer dieser Cookies. Läuft die Session ab, muss der HAR-Mitschnitt samt Cookies erneuert werden. Das Werkzeug ist außerdem für eine Aktion pro Lauf gedacht, nicht für einen dauerhaft betriebenen Integrationsdienst. Bei Plattformen mit rotierenden Tokens, signierten Requests oder gerätespezifischen Headern ist ein statischer Mitschnitt der falsche Ausgangspunkt.

Was stattdessen in Frage kommt

Die naheliegende Alternative ist die offizielle API der Zielplattform, sofern vorhanden. Der Unterschied liegt nicht im Komfort, sondern im Fundament: Ein offizieller Endpunkt ist ein Vertrag mit dokumentierten Parametern und Fehlercodes, den die Plattform einhält. Integuru v0 arbeitet dagegen gegen ein internes Interface, das die Plattform jederzeit ändern darf, ohne jemanden zu benachrichtigen. Wo keine offizielle API existiert, ist der verbreitete Weg die Browser-Automatisierung mit Playwright oder Selenium. Deren Ansatz ist grundlegend anders: Sie bedient die Oberfläche, also dieselben Requests, die ein Mensch auslöst, und bleibt damit innerhalb der Grenzen, die die Seite selbst zieht. Das ist langsamer und bricht, wenn sich das Layout ändert. Integuru v0 tauscht diese Anfälligkeit gegen eine andere: Der erzeugte Code hängt an Request-Formen, die sich ebenso ändern können, aber ohne sichtbare Warnung im DOM. Welcher der beiden Wege robuster ist, hängt davon ab, was die Plattform häufiger ändert.

Lizenz und Wartungskosten

Integuru steht unter AGPL-3.0. Diese Lizenz verlangt, dass abgeleitete Werke, die über ein Netzwerk genutzt werden, ebenfalls unter AGPL gestellt und im Quelltext verfügbar gemacht werden. Wer den erzeugten Code in einen eigenen Dienst einbettet, sollte das vorher mit einer Rechtsabteilung klären; eine Einschätzung kann dieser Text nicht liefern. Für die Wartung zählt etwas anderes: Das Repository ist nicht archiviert, der letzte Push liegt laut Metadaten im Juni 2026, und es wurden keine Releases abgerufen. Es gibt also keinen versionierten Stand, an dem man sich festhalten könnte. Änderungen landen auf main. Dazu kommt der laufende Modellaufruf pro Analyse, dessen Kosten das README nicht beziffert. Wer den Agenten regelmäßig auf neue Mitschnitte ansetzt, zahlt pro Lauf, nicht einmalig.

Redaktionelles Fazit

Integuru v0 ist für Automatisierungs- und RPA-Teams interessant, die eine einzelne, klar beschriebene Aktion gegen eine Plattform ohne öffentliche API wiederholbar machen wollen und dafür Cookies und einen HAR-Mitschnitt bereitstellen können. Wer eine gepflegte Integrationsbibliothek, mehrere gleichzeitige Nutzer oder eine rechtliche Bewertung des Zugriffs auf interne Endpunkte braucht, ist hier falsch. Vor dem ersten Einsatz zu klären: ob die Zielplattform den Zugriff auf interne Endpunkte in ihren Bedingungen untersagt, wie lange die Session-Cookies gültig bleiben und ob das Ergebnis aus --generate-code nach einem Token-Ablauf noch läuft.

Offizielle Quellen

1. Integuru-AI/Integuru on GitHub
2. Issues
3. License: AGPL-3.0
4. Project website
5. README