How Do Unified API Platforms Handle Systems With No API?

Unified API platforms don't handle systems with no API. They work by translating many existing APIs into one common format, so if a piece of software has no API, there is nothing for them to translate. For those systems you need a different kind of tool: one that works through the software's screens like a person would, or one that uses the hidden calls the software's own web pages make.

This guide explains where unified APIs stop, the two main ways to reach software that has no API, and how to choose between them for a product or a client project.

What does a unified API platform actually do?

A unified API sits between your product and many similar tools, such as CRMs, accounting packages or HR systems. You build one integration with the platform, and it connects to each vendor's own API behind the scenes, converting their different data into one shared model.

So instead of writing separate integrations for HubSpot, Salesforce and Pipedrive, you write one, and the platform handles the differences. That saves real time when your customers use many different tools in the same category.

The catch is in the definition. Every connection the platform offers is built on top of a vendor's API. The platform's job is translation and maintenance, not access.

How do unified APIs handle systems with no API?

They don't. If the software has no API, it won't appear in the platform's list of integrations, because there is nothing to connect to.

What unified APIs do offer is a way to reach the parts of an API their shared model doesn't cover. Merge, one of the best-known platforms, calls this an authenticated passthrough request: it lets you send requests directly to an integration's own API, using the customer's stored credentials, when you need data Merge doesn't fetch itself. Responses come back in the vendor's own format, not the shared model, so your code has to handle them per vendor.

A passthrough is useful for edge cases, but it still needs the vendor to have an API. It is a way around the common model, not a way around a missing API.

This matters because the software that most needs connecting often has no API at all: older industry systems, government and insurer portals, supplier websites and many niche tools that small businesses depend on.

What can you use instead when there's no API?

There are two main approaches. Both treat the software's web interface as the way in, but they work at different layers.

Option 1: Browser agents that use the screens

Browser automation tools log in to the software and work through its screens: clicking, typing, filling in forms and reading the results, the way a member of staff would. Older robotic process automation (RPA) tools did this with fixed scripts. Newer services use AI agents that can cope better when a page changes slightly.

Deck is one example of the newer kind. It describes its service as authenticated access to websites that don't have an API: agents that log in, navigate and fill out forms, including on sites with two-factor sign-in, and return the results through a REST API as structured data.

Strengths: it works with almost anything a person can use in a browser, and it doesn't depend on how the site is built behind the scenes.

Weaknesses: it is slower, because it waits for real pages to load, and it can still break when screens are redesigned.

Option 2: Using the network calls behind the screens

Most modern web applications load their data from the vendor's own servers using hidden requests, which the vendor's pages make every time someone clicks. These requests are effectively a private API that the vendor never published.

Tools in this group record those requests once, then turn them into endpoints your product can call directly. Supergood describes its approach this way: it records a workflow in the portal once, captures the underlying network calls, and generates REST endpoints and tools for AI agents that call the vendor's back end directly, with no browser involved. Its own comparison argues that for high-volume work on software you don't own, this network approach beats driving a browser.

Strengths: much faster than a browser, and closer to a real API to work with.

Weaknesses: the vendor can change those private calls at any time without notice, because they were never meant for outside use, so you need monitoring and someone to fix breakages.

How do the options compare?

Many real projects use more than one. A typical pattern is a unified API for the common tools, plus a browser or network-based connector for the one industry system that has no API.

What should you check before connecting to software with no API?

Reaching software through its screens or private calls raises questions a normal API integration doesn't:

• Permission. Get the customer's written agreement to act in their account, and read the software vendor's terms of use. Some terms restrict automated access.
• Credentials. You will be storing someone's login. Use a provider or design that keeps credentials encrypted and handles two-factor sign-in properly, and never share one login across customers.
• Data protection. If personal data passes through, you are processing it on someone's behalf. Make sure your contracts cover this.
• Breakage. Agree up front who notices and fixes an integration when the software changes, and how quickly. This is the real ongoing cost.
• Volume. Check how often you need to sync. A few actions a day suits a browser agent; thousands an hour points towards a network-level approach or asking the vendor for proper access.

It is also worth asking the vendor directly. Some have a private or partner API they don't advertise, or an export feature that solves the problem with far less risk.

For a fuller look at the options when software has no API, including file exports and database access, see our guide on how to integrate software that has no API. If you deliver integrations for clients as an MSP or IT consultancy, our guide to API integrations for MSPs covers how to price and support this work.

Frequently asked questions

If you need to connect a system that has no API, whether for your own product or a client, our custom software team can assess the options, from vendor exports to agent-based connectors, and build the one that will hold up. Book a free consultation and tell us which system you're trying to reach.