UnifAPI wird Partner von OOMOL: Lesezugriffe auf öffentliche Daten treffen OAuth-Schreibzugriffe

Kurz gesagt: UnifAPI ist jetzt ein nativer Provider in OOMOLs Open-Source-OpenConnector und spiegelt unseren vollständigen Katalog öffentlicher Daten — alle 16 Plattformen — als typisierte, aufrufbare Actions. Ein Admin verbindet UnifAPI einmal mit einem Workspace-API-Key; das ganze Unternehmen liest über diese geteilte Verbindung Live-Daten aus öffentlichen Quellen, direkt neben den OAuth-Schreib-Tools, die OOMOL bereits vermittelt. Offboarding ist ein Klick in OOMOL — auf UnifAPI-Seite muss nichts rotiert werden.

Agent-Integrationen haben sich schon immer in zwei Hälften geteilt. Eine Hälfte ist privat: das eigene Gmail, Notion, Linear, Slack des Nutzers — Daten, deren Zugriff nur dieser Nutzer autorisieren kann, meist über OAuth, meist mit Schreibzugriff. Die andere Hälfte ist öffentlich: Posts, Profile, Videos, Threads, Rankings, SERPs — Belege, die jeder mit einem Browser lesen könnte, und genau das ist das gesamte Produkt von UnifAPI.

Bis jetzt haben Teams diese Hälften getrennt verdrahtet: eine Connector-Plattform für die OAuth-Tools, ein direkter Key oder eine MCP-Verbindung für öffentliche Daten und zwei verschiedene Antworten auf die Frage „wer hat Zugriff, und wie widerrufen wir ihn?". Heute schließen wir diese Lücke. UnifAPI ist ein eingebauter Provider in OOMOLs OpenConnector, sodass die Öffentliche-Daten-Hälfte und die OAuth-Hälfte hinter einem Gateway, einem Katalog und einer Team-Management-Oberfläche leben.

Wer OOMOL ist

OOMOL baut Integrationsinfrastruktur für Agents und die Teams, die sie betreiben. Wenn Sie es mit Composio verglichen haben, liegen Sie in der richtigen Nachbarschaft — ein Connector-Gateway, das Auth zwischen Agents und Drittanbieter-Diensten vermittelt — aber OOMOL kam aus einer ungewöhnlichen Richtung dorthin, und dieser Umweg ist dem Produkt anzumerken.

Das Unternehmen tauchte Mitte 2025 zuerst auf Hacker News auf, mit OOMOL Studio, angekündigt als „local-first, code-first" Workflow-Automatisierungs-Engine (lokal zuerst, Code zuerst). Wo Zapier und n8n Ihnen eine Leinwand aus vorgefertigten Nodes und für alles andere eine beengte Ausdrucksbox geben, ist Studio auf einer VS-Code-Basis gebaut: Jeder Block in einem Workflow ist echtes Python oder Node.js und läuft in einem Container, sodass sich Drittanbieter-Bibliotheken auf jeder Maschine identisch verhalten. Unter der Leinwand sitzt OOCANA, eine in Rust implementierte Workflow-Engine, die Flows und Blocks ausführt, die in einfachen YAML-Dateien deklariert sind. Blocks und Workflow-Vorlagen sind teilbar, sodass Teams eine Bibliothek funktionierender Bausteine ansammeln statt Screenshots von Node-Graphen.

Um diesen Kern herum wuchs das Ökosystem so, wie Agent-Infrastruktur zu wachsen pflegt: oo CLI, ein Kommandozeilen-Relay, mit dem Agents veröffentlichte Tools suchen, inspizieren und ausführen können; OOMOL Cloud, die gehostete Laufzeitumgebung für Workflows, die kontinuierliche Auslieferung und verwaltete Konfiguration brauchen; und Wanta, eine Desktop-App, in der Sie Accounts einmal verbinden und dann in natürlicher Sprache über sie hinweg arbeiten.

Das Bindegewebe für all das ist OpenConnector — das Teil, in das UnifAPI sich jetzt einklinkt.

Ein Blick in OpenConnector

OpenConnector ist ein quelloffenes Connector-Gateway unter Apache-2.0-Lizenz. Sein Slogan lautet „Connect Once. Use Everywhere" (einmal verbinden, überall nutzen), und das ist wörtlich gemeint: Sie verbinden einen Account einmal, und ein geteilter Katalog von über 1.000 Providern und über 9.400 vorgefertigten Actions wird von jeder Oberfläche aus aufrufbar, die Ihr Team nutzt — ein TypeScript-SDK aus App-Code, das oo CLI als lokales Agent-Relay, MCP aus Agent-Hosts, einfaches HTTP/OpenAPI aus eigenen Clients und eine Web Console für Administration und Debugging.

Zwei Designentscheidungen sind für das Folgende entscheidend.

Erstens ist jede Action ein inspizierbarer Vertrag: Request-/Response-Schemas, benötigte Scopes und der Executor-Quellcode selbst sind alle lesbar. Sie können prüfen, was eine Action tut, bevor ein Agent sie jemals aufruft — dieselbe „Lies den Vertrag, nicht das Marketing"-Haltung, die wir mit OpenAPI einnehmen.

Zweitens sind Credentials architektonisch von den Agents getrennt, die sie nutzen. API-Keys und OAuth-Tokens sind at rest versiegelt (AES-256-GCM), Agents rufen über serverseitige Flows auf und sehen niemals ein rohes Secret, Allow/Block-Policies (Erlauben/Blockieren) begrenzen, welche Actions jeder Consumer aufrufen darf, und jeder Aufruf schreibt einen Audit-Eintrag — Akteur, Scope, Zeitstempel, Ergebnis — mit geschwärzten Outputs in den Run-Logs. Ein Agent, der aus dem Ruder läuft, kann auf der Policy-Ebene abgeschnitten werden; er hatte den Key von vornherein nie in der Hand.

Das ist die Maschinerie. Hier ist, warum UnifAPI dort hineingehört.

Augen treffen Hände

Die Positionierung von UnifAPI ist seit Tag eins konsistent: „eyes, not hands" (Augen, nicht Hände). Wir lesen öffentliche Daten — TikTok, LinkedIn, Instagram, YouTube, Twitter/X, Threads, Reddit, Hacker News, News, SEO- und GEO-Signale, Karten und lokale Einträge — normalisieren sie in einen Envelope und halten niemals Ihre Posting-Credentials. Recherche, Monitoring, Audits, Pricing: Lesezugriffe.

OOMOLs Katalog ist in der entgegengesetzten Hälfte am stärksten. Die meisten dieser über 1.000 Provider sind OAuth in privates SaaS — die Hände. Seine Verbindungen lassen einen Agent innerhalb der Accounts handeln, die der Nutzer tatsächlich besitzt: die Slack-Nachricht senden, die Notion-Seite aktualisieren, das Linear-Ticket anlegen, die E-Mail entwerfen.

Damit war die Lücke der einen Seite das Produkt der anderen. Ein Connector-Gateway voller Schreib-Tools braucht trotzdem Belege, auf deren Grundlage es handeln kann, und eine live gehaltene, normalisierte, rechtlich sorgfältige Öffentliche-Daten-Schicht zu bauen ist ein Vollzeit-Produkt, kein Feature. Eine Öffentliche-Daten-Schicht braucht trotzdem einen Ort, an dem Erkenntnisse landen, und OAuth in Hunderte SaaS-Apps zu vermitteln ist ebenso jemandes ganze Aufgabe. Stellt man beide hinter dasselbe Gateway, schließt sich die Schleife, ohne dass eine Seite ihr Modell kompromittiert:

„Finde heraus, was TikTok-Creator diese Woche über unseren Launch gesagt haben" → UnifAPI, öffentliche Lesezugriffe.

„Poste den Digest in #marketing und lege Follow-ups in Linear an" → OOMOLs OAuth-Verbindungen, private Schreibzugriffe.

Ihr Assistent ruft beides über einen Katalog auf. UnifAPI berührt weiterhin nie Ihre privaten Accounts — diese Grenze ist tragend, nicht zufällig — und OOMOL muss keine Öffentliche-Daten-Schicht pflegen, denn die Lesezugriffe kommen von einem Provider, dessen einzige Aufgabe es ist, sie live, normalisiert und pro Datensatz bepreist zu halten.

Ein Key, das ganze Unternehmen

Der Teil, der uns am meisten begeistert, ist, was OOMOLs Team-Schicht mit dem UnifAPI-Onboarding macht.

Ein UnifAPI-API-Key gehört zu einem Workspace und verbraucht dessen Credits. Vor dieser Partnerschaft bedeutete das Teilen im ganzen Unternehmen, was Key-Sharing immer bedeutet: in einen Vault oder eine Env-Datei einfügen, hoffen, dass er nie auf einen Laptop, in ein Notebook oder ein Repo leakt, und ihn jedes Mal rotieren, wenn jemand das Team verlässt — und dann jeder Stelle hinterherjagen, an der der alte Key gecacht war.

Über OOMOL funktioniert es so, wie Team-Credentials funktionieren sollten:

Ein Admin erstellt einen Key in der UnifAPI-Konsole und speichert ihn als UnifAPI-Verbindung in OOMOL — einmal. Alle im Team rufen UnifAPI über diese geteilte Verbindung auf, aus Studio-Workflows, Agents hinter dem oo CLI oder MCP oder Backend-Code über das SDK. Der rohe Key zirkuliert nie; Teamkollegen referenzieren die Verbindung über ihren Namen, während das Secret versiegelt im Gateway bleibt. Allow/Block-Policies entscheiden, welche Actions jeder Consumer aufrufen darf — der Recherche-Agent des Analysten kann TikTok und Reddit lesen, das Experiment des Praktikanten kommt nicht an die SEO-Endpunkte — und der Audit-Trail zeigt, welches System welche Verbindung wofür genutzt hat.

Und wenn jemand geht, entfernen Sie seinen Zugriff in OOMOL. Das war's. Keine Key-Rotation, keine Redeploys, keinerlei Änderungen auf UnifAPI-Seite — der Workspace-Key war von Anfang an nie in seinen Händen. Die Nutzung fließt weiter in denselben UnifAPI-Workspace, sodass die Abrechnung ein Guthaben, ein Ledger, pro Datensatz bleibt.

Jede UnifAPI-Plattform, als typisierte Actions

Das ist kein Logo-Tausch und kein dünner Wrapper um drei Endpunkte. Der UnifAPI-Provider in OpenConnector spiegelt unseren Katalog Plattform für Plattform: TikTok, Twitter/X, Instagram, YouTube, LinkedIn, Threads, Reddit, Hacker News, News, SEO, GEO, Maps, Local, Hotels, Events und Rendered-Browser-Fetch — dieselben 16 Plattformen und 220 Operationen hinter unifapi.com/apis, jede generiert als typisierte Action mit Input- und Output-Schemas, die ein Agent vor dem Aufruf inspizieren kann.

Weil die Actions aus typisierten Operationsdefinitionen generiert statt von Hand geschrieben werden, folgt der Provider unserer OpenAPI-Oberfläche: Wenn der Katalog wächst, wächst der Connector mit. Und die Abrechnung ändert unterwegs nicht ihre Form — Aufrufe über OOMOL verbrauchen Ihre UnifAPI-Workspace-Credits zum gleichen Preis pro Datensatz wie direkte HTTP- oder MCP-Nutzung, mit denselben billing-Metadaten in jeder Antwort.

Open Source, selbst hostbar

OpenConnector steht unter Apache 2.0, und der UnifAPI-Provider ist Teil des öffentlichen Katalogs — Sie können den Provider-Quellcode selbst lesen: API-Key-Auth, gesendet als Standard-Bearer-Header, Actions pro Plattform generiert.

Das zählt, weil die Team-Geschichte oben nicht erfordert, einer gehosteten Blackbox zu vertrauen. Sie können das gesamte Gateway auf Infrastruktur betreiben, die Sie kontrollieren — lokal via Docker oder Node.js, auf Fly.io mit persistentem SQLite oder auf Cloudflare Workers mit D1 und R2 — und erhalten den identischen Provider-Katalog und dieselben Action-Verträge. OOMOLs gehostete Laufzeitumgebung ist der Zero-Ops-Pfad mit derselben Schnittstelle: gehostet zu starten und später auf Self-Hosting zu wechseln (oder umgekehrt) ändert Ihren Integrationscode nicht.

Für Teams, deren Security-Review davor zurückschrecken würde, Credentials durch ein Drittanbieter-SaaS zu leiten, ist das der Unterschied zwischen „interessant" und „freigegeben": Der Credential-Store, die Policy-Engine und das Audit-Log können allesamt innerhalb Ihres eigenen Perimeters leben.

UnifAPI über OOMOL verbinden

Das Setup ist bewusst unspektakulär:

1. Melden Sie sich in der UnifAPI-Konsole an und erstellen Sie einen Workspace-API-Key (er wird einmal angezeigt, mit dem Präfix unif_).
2. Fügen Sie in OOMOL eine UnifAPI-Verbindung hinzu und fügen Sie den Key ein. OpenConnector übernimmt ab dort den Authorization: Bearer-Header.
3. Rufen Sie UnifAPI-Operationen von überall dort auf, wo Ihr Team arbeitet — Studio-Workflows, das oo CLI, MCP-verbundene Assistenten oder das SDK aus Backend-Code.

Wenn Sie als einzelner Operator Skills in Claude oder Codex betreiben, bleibt der direkte Pfad auf unifapi.com/mcp das Drei-Minuten-Setup. OOMOL ist der Pfad, der UnifAPI zu einem Team-Werkzeug macht: geteilte Verbindung, begrenzte Policies, Audit-Trail, Ein-Klick-Offboarding.

Drei Schleifen, die sich damit schließen

Ein paar Workflows, die früher zwei Integrationsprojekte brauchten und jetzt ein Gateway:

Social Listening, Ende zu Ende. Ein Workflow liest Markenerwähnungen über Reddit, TikTok und Twitter/X hinweg durch UnifAPI, bewertet sie in einem Python-Block und postet über eine OAuth-Verbindung einen Morgen-Digest in den Slack des Teams — öffentlich lesen, privat schreiben, ein Katalog, ein Audit-Trail.

Influencer-Marketing mit Belegkette. Ein Workflow erstellt aus öffentlichen Engagement-Daten eine Creator-Shortlist und bepreist KOLs und schreibt die Shortlist dann — mit den zitierten öffentlichen Belegen — zur Prüfung in den Notion-Workspace des Teams. Wenn Finance fragt, woher eine Zahl stammt, antwortet das Run-Log.

Competitive Intelligence, die ihre eigenen Tickets anlegt. Ein geplanter Workflow beobachtet die öffentlichen Launches, Threads und Rankings von Wettbewerbern und macht aus allem Umsetzbaren Tickets im Tracker des Teams, jedes mit Link zurück zur öffentlichen Quelle.

In jedem Fall bleibt die Grenze sauber: UnifAPI liefert zitierbare öffentliche Belege; die eigenen Accounts des Nutzers, autorisiert über OOMOL, tragen die Aktionen.

Das größere Bild

Agents haben irgendwann letztes Jahr aufgehört, ein Solo-Werkzeug zu sein. In dem Moment, in dem ein Workflow geteilt wird — ein Team-Digest in Slack, eine unternehmensweite Recherche-Pipeline, ein geplantes Audit — ändern sich die Fragen von „welches Modell?" zu „wer darf was aufrufen, mit wessen Credentials, und was passiert, wenn diese Person geht?". Das sind Gateway-Fragen, und deshalb sind Connector-Gateways zu einer eigenen Schicht des Agent-Stacks geworden.

Unsere Antwort hat zwei Teile. Für die Öffentliche-Daten-Hälfte bleibt UnifAPI, was es ist: ein Key, ein Envelope, Preis pro Datensatz, read-only by design. Für die Team-Hälfte integrieren wir uns lieber mit einem offenen, inspizierbaren Gateway, als eine Schattenkopie davon zu bauen. OOMOLs OpenConnector ist genau das — Open Source, selbst hostbar, mit einem Sicherheitsmodell, auf das wir unsere eigenen Kunden verweisen können.

Einmal verbinden. Das ganze Unternehmen liest das öffentliche Web.

Was Sie als Nächstes lesen sollten

UnifAPI vs. Composio – die Zwei-Hälften-Rahmung, auf der diese Partnerschaft aufbaut.

UnifAPI via MCP mit Claude verbinden – der direkte MCP-Pfad für einzelne Operatoren.

Der minimal tragfähige Agent-Stack – wo ein Connector-Gateway und eine Öffentliche-Daten-Schicht in einer Architektur sitzen.