When There's No API, the Browser Is the API

An AI agent is only as useful as the systems it can touch. A voice agent that can hold a perfect conversation but cannot actually book the appointment is a demo, not a product. So the real constraint on agent automation is rarely the model. It is integration: can the agent read and write the system of record the business actually runs on?

For a large share of the platforms small businesses depend on, the conventional answer is "no." A booking platform, a clinic management system, a salon scheduler: many expose no public API at all, or offer a thin one that omits the operations you need, or gate the real API behind an enterprise tier the customer will never buy. The standard integration playbook stops there. Ours doesn't.

The reframe

A platform without an API is not a platform without an interface. It has a very rich, very well-tested interface: the web application its own users log into every day. Staff create bookings, reschedule them, pull up a client's history, take a payment. Every one of those actions is reachable through the browser, because that is the only way the platform's own customers do them.

So the question stops being "does this platform have an API?" and becomes "can a human do this in a browser?" If the answer is yes, an agent can do it too, by driving that same browser with Playwright. The web UI becomes the integration surface. The browser is the API.

What this looks like in practice

We run headless Chromium under Playwright, server-side, and treat each platform's UI as a set of operations exposed to the agent as tools. For a booking platform that means the obvious verbs:

• Authenticate as the business, the same way their staff log in.
• Read the schedule, availability, and client records.
• Create a booking, reschedule it, cancel it, change its status.
• Create or update a customer record.

The agent doesn't know or care that there's a browser underneath. It calls a tool like createBooking(...) exactly as it would call a REST endpoint; behind that tool, Playwright navigates the platform's pages, fills the same forms a receptionist would, waits for the same confirmations, and returns structured data back to the model. From the agent's side it is just another capability. From the platform's side it is just another logged-in session.

This is how we've integrated scheduling and clinic platforms across the board, including ones with no usable public API. The pattern is the same each time; only the selectors and the login flow change.

The hard parts (and how we handle them)

Browser automation is easy to demo and hard to run in production. The difference is entirely in the parts that aren't the happy path.

Sessions, not logins. Logging in is the slow, fragile, sometimes MFA-guarded step. You do not want to do it on every request. So we authenticate once, persist the resulting browser context (its cookies and storage), and reuse the session across many operations. A scheduled health check pings each integration's session, detects when one has expired, and re-authenticates proactively, before an agent ever hits a logged-out page. The agent experiences a warm, always-logged-in connection; the messy re-auth happens out of band.

Credentials, encrypted and per-tenant. Driving a UI means holding real login credentials. Those are encrypted at rest per business (we use envelope encryption via a managed KMS) and only decrypted in memory at the moment a session needs establishing. The automation layer never stores a credential in the clear.

API where it exists, browser where it doesn't. This is not an anti-API stance. Where a platform offers a real endpoint for an operation, we use it: it is faster, cheaper, and more stable than driving a page. Several of our integrations are hybrids, calling the official API for the operations it covers and falling back to Playwright only for the ones it doesn't. Browser automation is the universal fallback, not the first choice.

Anti-bot and scale. Some platforms actively fight automation. Hardened headless flags handle the basics; for the harder cases we can route a session through a managed scraping browser with residential egress instead of local Chromium. The agent-facing tool is identical either way.

The honest trade-offs

This method is powerful, not free, and it is worth being clear about the costs:

• Fragility. A UI is an undocumented, unversioned contract. When the platform ships a redesign, selectors break. Real APIs change far less often. Mitigation is monitoring and fast selector maintenance, not pretending it won't happen.
• Latency and cost. Driving a browser is heavier than an HTTP call: more time, more compute. For high-volume paths a real API wins decisively, which is exactly why we use one when it's there.
• Terms of service. Automating a platform on a customer's own behalf, with the customer's own credentials and consent, is a different posture from scraping a third party. We treat that line seriously and integrate only on behalf of the account holder.

None of these are reasons not to do it. They are reasons to engineer it properly: sessions, encryption, monitoring, and a real API wherever one is offered.

The payoff

Reframing integration around the browser changes what "integrable" means. The set of systems an AI agent can act inside is no longer limited to the ones with a developer portal and an API key. It expands to every system a human can operate, which is to say, all of them.

Across the scheduling, salon, and clinic platforms our customers actually run on, with this method we have not yet found a platform we cannot integrate with our AI-powered agents. If your staff can do it in a browser, our agents can do it too, on your behalf, around the clock. The API was never the point. The capability was.