What Is an Unofficial API?

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, built by reverse-engineering what the app's own front-end already does.

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.

Unofficial API vs web scraper

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:

• Atomic operations. It's tuned for discrete actions: update one customer record, pull a structured business filing, post a single order.
• A contract. Someone owns the maintenance. There's a documented performance expectation. You can wire it into a production workflow without flinching.

Infrastructure lags innovation

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.

Why LLMs make unofficial APIs work at scale

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.

Unofficial API vs browser automation and computer use

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:

• Latency. Seconds per click. A workflow that's 30 steps deep is slow in a way users notice.
• Token cost. Every screen the model looks at is tokens. It adds up fast at volume.
• UI drift. The vendor moves a button and the flow breaks. You're maintaining against someone else's redesign schedule.
• Auth. MFA prompts and CAPTCHAs exist to stop exactly this. Sometimes you can get past them; it's never clean.
• Scale. Running hundreds of logged-in browser sessions in parallel is its own infrastructure problem.
• Security. You're handing an autonomous agent a logged-in session inside a customer's system. That's a real surface to defend.

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.)

What it looks like in vertical software

PropTech is the textbook case. A lot of these companies need Zillow's rental and listing data, which lives behind a login with no public API. An unofficial API for that gives them:

• A REST interface that looks like the official API they wish existed.
• Credential and MFA handling, managed.
• Normalized response shapes.
• Resilience to UI changes, because the integration is maintained: a redesign is a patch, not an outage.

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.

What makes an unofficial API good

3 things separate an unofficial API you'd build a product on from a script you'd be embarrassed to ship:

• Managed. Monitored and tested continuously, so breakage gets caught upstream of your customers.
• Purpose-built. It exposes the specific operations a developer actually needs, not a firehose of everything.
• Reliable. SLAs that hold up next to an official API. If you can't lean on it, it isn't infrastructure.

This is what Supergood builds: unofficial APIs (and MCP servers) for the enterprise software that doesn't offer one, generated through automated reverse-engineering and 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.