An unofficial API is a clean, documented way to read and write data from software that doesn't officially offer one. How they differ from scrapers and browser bots, why LLMs make them work at scale, and what makes one good.

An unofficial API is a programmatic interface to data or functionality that the provider doesn't officially offer.
The product has a web app. Maybe a partner program, maybe nothing. An unofficial API gives you a clean, documented way to read and write that data anyway, derived from the network requests the app's own front-end already makes.
If you've ever needed your software to talk to a system that just doesn't have an API, this is the layer that bridges the gap.
People mix unofficial APIs up with web scrapers. They're different animals.
A scraper grabs HTML off a page and parses it. Brittle, usually read-only, breaks the moment the markup shifts.
An unofficial API is built for sustained, two-way interaction. 2 things follow from that:
Unofficial APIs aren't new, and the pattern isn't subtle.
Plaid is the cleanest example. In 2013, banking infrastructure was stuck in the past while consumer demand for digital money management kept climbing. Plaid didn't wait for the banks to upgrade. It built the integration layer itself.
AI agents are on the same track. They're great at chewing through unstructured data and stringing together task sequences, but they need a well-defined set of tools to call. The math doesn't balance: agent use cases are effectively infinite, and the APIs that exist are finite, especially in the vertical software that never shipped one.
Maintenance is what always killed unofficial APIs. The integration was bespoke code only the person who wrote it understood, and it broke every time the underlying app changed. So most teams kept their distance.
LLMs change the cost structure. A model can read the app's docs (such as they are), adapt the integration code when something shifts, and, with the right instrumentation, diagnose a failure and propose the fix.
The maintenance that used to need a dedicated engineer now needs a model plus a human checking its work. That's the difference between a one-off hack and something you can build a product on.
There's another way to make software do things without an API: drive its interface with a bot.
Old-school RPA does it with recorded scripts. The newer flavor does it with an LLM: "computer use" agents, browser-automation tools like Browser Use, Browserbase, Stagehand, Skyvern, MultiOn, Playwright on its own.
These are genuinely useful. No API required, quick to prototype, fine for a one-off task or a low-volume internal flow.
In production integrations, they fall apart in predictable ways:
An unofficial API sidesteps all of it. It talks to the same underlying endpoints the app's front-end uses, but as a normal REST API: deterministic, fast, structured responses, and someone monitoring it so a vendor change gets caught and patched instead of discovered by a customer. (Often it's surfaced to a model as an MCP server, which is how AI agents plug into it natively.)
PropTech is the textbook case. A lot of these companies need rental and listing data from a portal like Zillow, which lives behind a login with no public API. An unofficial API for a platform like that could give them:
Same story in legal tech, gov tech, insurance, healthcare. Wherever the system of record is an incumbent that never opened up, the API gap is the thing slowing everyone down.
3 things separate an unofficial API you'd build a product on from a script you'd be embarrassed to ship:
This is what Supergood builds: unofficial APIs (and MCP servers) for the enterprise software that doesn't offer one, generated from the platform's own network requests with human-in-the-loop code review, with observability so the integration keeps working when the vendor changes things.
If you're trying to make your software talk to a system that won't meet you halfway, that's the problem we solve.
That's a question for your counsel and the platform's terms of service; there's no blanket answer. The framing that matters in practice: a production-grade unofficial API works on behalf of an authenticated user, scoped to that user's own account, reading and writing only data the user can already access through the app itself.
Closely related but not the same thing. The private API is the set of endpoints a platform's own front-end calls; an unofficial API is a documented, maintained interface built on top of those endpoints, with a contract, monitoring, and normalized responses so other software can depend on it.
A scraper grabs HTML off a page and parses it: brittle, usually read-only, and it breaks the moment the markup shifts. An unofficial API is built for sustained two-way interaction, with atomic operations (update one record, post one order) and a maintenance contract you can wire into a production workflow.