UnifAPI partners with OOMOL: public-data reads meet OAuth writes

In short: UnifAPI is now a native provider in OOMOL's open-source OpenConnector, mirroring our full public-data catalog — all 16 platforms — as typed, callable Actions. One admin connects UnifAPI once with a workspace API key; the whole company reads live public data through that shared connection, next to the OAuth write tools OOMOL already brokers. Offboarding is one click in OOMOL — nothing to rotate on the UnifAPI side.

Agent integrations have always split into two halves. One half is private: the user's own Gmail, Notion, Linear, Slack — data only that user can authorize, usually via OAuth, usually with write access. The other half is public: posts, profiles, videos, threads, rankings, SERPs — evidence anyone with a browser could read, which is UnifAPI's entire product.

Until now, teams wired those halves separately: a connector platform for the OAuth tools, a direct key or MCP connection for public data, and two different answers to "who has access, and how do we revoke it?" Today we're closing that gap. UnifAPI is a built-in provider in OOMOL's OpenConnector, so the public-data half and the OAuth half live behind one gateway, one catalog, and one team-management surface.

Who OOMOL is

OOMOL builds integration infrastructure for agents and the teams that run them. If you've compared it to Composio, that's the right neighborhood — a connector gateway that brokers auth between agents and third-party services — but OOMOL arrived there from an unusual direction, and the detour shows in the product.

The company first surfaced on Hacker News in mid-2025 with OOMOL Studio, pitched as a local-first, code-first workflow automation engine. Where Zapier and n8n give you a canvas of prebuilt nodes and a cramped expression box for everything else, Studio is built on a VS Code base: every block in a workflow is real Python or Node.js, running in a container so third-party libraries behave identically on any machine. Under the canvas sits OOCANA, a workflow engine implemented in Rust that schedules flows and blocks declared in plain YAML files. Blocks and workflow templates are shareable, so teams accumulate a library of working pieces instead of screenshots of node graphs.

Around that core, the ecosystem grew the way agent infrastructure tends to: oo CLI, a command-line relay that lets agents search, inspect, and run published tools; OOMOL Cloud, the hosted runtime for workflows that need continuous delivery and managed configuration; and Wanta, a desktop app where you connect accounts once and work across them in natural language.

The connective tissue for all of it is OpenConnector — the piece UnifAPI now plugs into.

Inside OpenConnector

OpenConnector is an Apache-2.0 open-source connector gateway. Its tagline is "Connect Once. Use Everywhere," and it means it literally: you connect an account once, and a shared catalog of 1,000+ providers and 9,400+ prebuilt Actions becomes callable from whatever surface your team uses — a TypeScript SDK from app code, the oo CLI as a local agent relay, MCP from agent hosts, plain HTTP/OpenAPI from custom clients, and a Web Console for administration and debugging.

Two design decisions matter for what follows.

First, every Action is an inspectable contract: request/response schemas, required scopes, and the executor source itself are all readable. You can audit what an Action does before an agent ever calls it — the same "read the contract, not the marketing" posture we take with OpenAPI.

Second, credentials are architecturally separated from the agents that use them. API keys and OAuth tokens are sealed at rest (AES-256-GCM), agents call through server-side flows and never see a raw secret, allow/block policies scope which Actions each consumer may invoke, and every call writes an audit record — actor, scope, timestamp, result — with redacted outputs in the run logs. An agent that goes off the rails can be cut off at the policy layer; it never held the key to begin with.

That's the machinery. Here's why UnifAPI belongs inside it.

Eyes meet hands

UnifAPI's positioning has been consistent from day one: eyes, not hands. We read public data — TikTok, LinkedIn, Instagram, YouTube, Twitter/X, Threads, Reddit, Hacker News, news, SEO and GEO signals, maps and local listings — normalize it into one envelope, and never hold your posting credentials. Research, monitoring, audits, pricing: reads.

OOMOL's catalog is strongest in the opposite half. Most of those 1,000+ providers are OAuth into private SaaS — the hands. Its connections let an agent act inside accounts the user actually owns: send the Slack message, update the Notion page, file the Linear ticket, draft the email.

That made each side's gap the other side's product. A connector gateway full of write tools still needs evidence to act on, and building a live, normalized, legally careful public-data layer is a full-time product, not a feature. A public-data layer still needs somewhere for findings to land, and brokering OAuth into hundreds of SaaS apps is equally somebody's whole job. Put both behind the same gateway and the loop closes without either side compromising its model:

"Find what TikTok creators said about our launch this week" → UnifAPI, public reads.

"Post the digest to #marketing and file follow-ups in Linear" → OOMOL's OAuth connections, private writes.

Your assistant calls both through one catalog. UnifAPI still never touches your private accounts — that boundary is load-bearing, not incidental — and OOMOL doesn't have to maintain a public-data layer, because the reads come from a provider whose only job is keeping them live, normalized, and priced per record.

One key, the whole company

The part we're most excited about is what OOMOL's team layer does to UnifAPI onboarding.

A UnifAPI API key belongs to a Workspace and spends that workspace's credits. Before this partnership, sharing it across a company meant what key-sharing always means: paste it into a vault or an env file, hope it never leaks into a laptop, a notebook, or a repo, and rotate it every time someone leaves — then chase down every place the old key was cached.

Through OOMOL it works the way team credentials should:

One admin creates a key in the UnifAPI console and saves it as a UnifAPI connection in OOMOL — once. Everyone on the team calls UnifAPI through that shared connection, from Studio workflows, agents behind the oo CLI or MCP, or backend code on the SDK. The raw key never circulates; teammates reference the connection by name while the secret stays sealed inside the gateway. Allow/block policies decide which Actions each consumer may call — the analyst's research agent can read TikTok and Reddit, the intern's experiment can't touch the SEO endpoints — and the audit trail shows which system used which connection for what.

And when someone leaves, you remove their access in OOMOL. That's it. No key rotation, no redeploys, no changes on the UnifAPI side at all — the workspace key was never in their hands to begin with. Usage keeps flowing into the same UnifAPI workspace, so billing stays one balance, one ledger, per record.

Every UnifAPI platform, as typed Actions

This isn't a logo swap or a thin wrapper around three endpoints. The UnifAPI provider in OpenConnector mirrors our catalog platform for platform: TikTok, Twitter/X, Instagram, YouTube, LinkedIn, Threads, Reddit, Hacker News, News, SEO, GEO, Maps, Local, Hotels, Events, and rendered-browser fetch — the same 16 platforms and 220 operations behind unifapi.com/apis, each generated into a typed Action with input and output schemas an agent can inspect before calling.

Because the Actions are generated from typed operation definitions rather than hand-written, the provider tracks our OpenAPI surface: when the catalog grows, the connector grows with it. And billing doesn't change shape in transit — calls through OOMOL spend your UnifAPI workspace credits at the same per-record price as direct HTTP or MCP usage, with the same billing metadata in every response.

Open source, self-hostable

OpenConnector is Apache 2.0, and the UnifAPI provider ships in the public catalog — you can read the provider source yourself: API-key auth, sent as a standard Bearer header, actions generated per platform.

That matters because the team story above doesn't require trusting a hosted black box. You can run the whole gateway on infrastructure you control — locally via Docker or Node.js, on Fly.io with persistent SQLite, or on Cloudflare Workers with D1 and R2 — and get the identical provider catalog and Action contracts. OOMOL's hosted runtime is the zero-ops path with the same interface, so starting hosted and moving self-hosted later (or the reverse) doesn't change your integration code.

For teams whose security review would balk at routing credentials through a third-party SaaS, this is the difference between "interesting" and "approved": the credential store, the policy engine, and the audit log can all live inside your own perimeter.

Connecting UnifAPI through OOMOL

The setup is deliberately boring:

1. Sign in to the UnifAPI console and create a workspace API key (it's shown once, prefixed unif_).
2. In OOMOL, add a UnifAPI connection and paste the key. OpenConnector handles the Authorization: Bearer header from there.
3. Call UnifAPI operations from wherever your team works — Studio workflows, the oo CLI, MCP-connected assistants, or the SDK from backend code.

If you're an individual operator running Skills in Claude or Codex, the direct path at unifapi.com/mcp remains the three-minute setup. OOMOL is the path that makes UnifAPI a team utility: shared connection, scoped policies, audit trail, one-click offboarding.

Three loops this closes

A few workflows that used to take two integration projects and now take one gateway:

Social listening, end to end. A workflow reads brand mentions across Reddit, TikTok, and Twitter/X through UnifAPI, scores them in a Python block, and posts a morning digest to the team's Slack through an OAuth connection — reads public, writes private, one catalog, one audit trail.

Influencer marketing with a paper trail. A workflow shortlists creators and prices KOLs from public engagement data, then writes the shortlist — with the public evidence cited — into the team's Notion workspace for review. When finance asks where a number came from, the run log answers.

Competitive intelligence that files its own tickets. A scheduled workflow watches competitors' public launches, threads, and rankings, and turns anything actionable into tickets in the team's tracker, each linking back to the public source.

In every case the boundary stays clean: UnifAPI supplies citable public evidence; the user's own accounts, authorized through OOMOL, carry the actions.

The bigger picture

Agents stopped being a solo tool sometime last year. The moment a workflow is shared — a team Slack digest, a company research pipeline, a scheduled audit — the questions change from "which model?" to "who can call what, with whose credentials, and what happens when they leave?" Those are gateway questions, and they're why connector gateways have become their own layer of the agent stack.

Our answer has two parts. For the public-data half, UnifAPI stays what it is: one key, one envelope, per-record pricing, read-only by design. For the team half, we'd rather integrate with an open, inspectable gateway than build a shadow copy of one. OOMOL's OpenConnector is exactly that — open source, self-hostable, with a security model we can point our own customers at.

Connect once. The whole company reads the public web.

What to read next

UnifAPI vs Composio - the two-halves framing this partnership is built on.

Connect UnifAPI to Claude via MCP - the direct MCP path for individual operators.

Minimum viable agent stack - where a connector gateway and a public-data layer sit in one architecture.