Why we built UnifAPI

Every interesting agent application we've ever built has eventually needed the same thing: a way for the model to read the open web. Find tweets about a product. Watch a YouTube transcript. Look something up on Google. Scrape a news article.

Doing that today means assembling a bag of vendors. Each one ships a different request shape, a different auth scheme, a different billing model, a different reliability bar. The plumbing eats more engineer-time than the agent itself.

The trade we kept making

Either we picked a hyperscaler scraping platform (Apify, Bright Data) and learned their actor model, or we bought a slice from a specialist (SerpAPI, Firecrawl, Tavily) for one capability and stitched it together with whatever we could find on RapidAPI for the rest.

RapidAPI is the worst of both worlds: thousands of APIs, none of them consistent, billed through subscriptions with hard request caps that punish growth. The moment your usage spikes, you either pay for 10x the tier or you get cut off.

What UnifAPI is

UnifAPI is one key, one bill, one consistent surface — for the public-data subset that agents actually need. Social platforms. Search and SERPs. Web scrape. News.

We don't do OAuth-based connectors to your own accounts. That's Composio's territory and they do it well. We're the other half: everyone else's data, on the open web, agent-ready.

What we believe

Pricing should be pay-per-call. Subscriptions and hard caps belong to a previous era of SaaS billing. If you want to call us once a month or a million times a month, the bill should match. We don't punish growth.

DX is the product. One key. Predictable JSON. OpenAPI spec. Typed SDKs. An MCP server for Claude and Cursor. The interface is what we sell — the underlying data is mostly the same as what's been out there.

We're early. If you're shipping an agent that reaches for the open web, come talk to us — we're picking a small set of design partners now.