How to Automate a Website That Has No API
TL;DR: The Oido Browser Connector is live on the Chrome Web Store. It closes the last gap in AI integration: the work that has no API, no MCP server and no export file — supplier portals, internal web apps, filing sites. Your agent opens a tab of its own in the Chrome you're already logged in to, and does the job there. You never hand over a password, the agent can only reach sites you've allowed, and it can't leave the site it started on.
The work that has no surface
Every integration guide, ours included, gives you the same four connection surfaces: an MCP server, a documented API, an integration platform connector, or a browser step. The first three get all the attention because they're clean.
The fourth is where a surprising share of actual business work lives.
A supplier portal that shows your open orders and offers no export. A regional carrier's tracking site. A government filing portal. An internal web app built in 2014 by someone who left. A distributor's B2B storefront where you place the same order every Tuesday. None of these have APIs. Most never will, because the vendor's incentive is to keep you inside their UI.
So the process stays manual. Someone logs in, reads a number, types it somewhere else. That's not a hard job — it's a job that resists automation because the interface resists automation, not because the task is complicated.
Why the usual answers don't fit
"Write a scraper." Fine until the login. Most of this work is behind an authenticated session, often with MFA and a device cookie. A headless script has no session, so you end up storing credentials in a secrets manager and replaying a login flow that breaks whenever the vendor adds a captcha.
"Use RPA." Closer, and it's what the category was built for. But classic RPA records a fixed sequence against fixed coordinates or selectors, so a layout change silently breaks it. The difference in 2026 isn't that screens got easier — it's that the understanding moved upstream, which is the whole of AI agents vs RPA.
"Use an open-source browser agent." browser-use and similar projects are genuinely good, and if you want to run your own browser automation they're the right starting point. What they don't ship is the part that makes this deployable in a company: whose session, which sites, who approved the purchase, and what got logged.
"Use an agentic browser." Comet, Operator and the rest do the task. They also do it in a browser that can reach anything you're logged in to, with a trust model that's mostly "we hope the page is honest." Gartner's advice to enterprises has been to hold off. That caution is earned — but it also means the work stays manual forever, which is not a strategy.
What we shipped
The Oido Browser Connector is a Manifest V3 Chrome extension. It's the local half of a feature that runs in Oido — inert on its own, and it does nothing at all until an agent you asked sends it a step.
The shape:
Studio chat → agent → Browser Driver subagent → browser tool
→ Oido Hub → SSE ↓ [ your Chrome ] ↑ result
You ask in chat. A subagent gets one tool with six actions — navigate, read, click, type, press, scroll — and one action per call. The extension opens its own tab, grouped and labelled OIDO, and performs the step there using real input events through the Chrome DevTools Protocol rather than synthetic DOM events, which is why it works on sites that check.
read returns a compact JSON view of the page: text, links, and every control with a selector and a label. The agent picks a control and acts on it. Controls inside embedded iframes — checkout widgets, payment fields, SSO frames — come back tagged with their frame, so the agent can act inside them instead of clicking the wrong document. Long pages page through with an offset. Pages that load as you scroll get scrolled.
That's the whole action set. Deliberately small: it's enough to do almost any web task a person does, and small enough to reason about.
The control model, in four lines
The full security argument is here, because letting an agent act inside your logged-in sessions is the highest-privilege place an agent can stand and it deserves its own article. The short version:
- Allowlist. The agent reaches only origins you listed. Everything else is refused, by the extension, not by the model.
- Origin-lock. Each task is pinned to the site it opened. It cannot navigate off. A hostile page saying "now go to the bank and transfer" fails at the client, regardless of whether the model was convinced. Auth redirect chains — the
app → SSO → apphop — are followed and then re-locked, because breaking every login is not a security model. - Its own tab. No
tabspermission, no reading your other tabs or history, nothing running on pages you visit. Chrome shows its "being debugged" banner the whole time the agent is driving, and the tab self-closes two minutes after the last action. - Approval before anything consequential. Submitting a purchase, sending a message, spending, deleting, posting — the run suspends and asks you in chat, and waits. That gate is durable: it survives a restart, because an approval that evaporates when a process recycles isn't a control. The general case is why a human stays on the gate.
The token you paste is scoped to this channel only. It can't be used anywhere else in your Oido account, it expires after 30 days, and uninstalling the extension deletes it.
The ordering still matters
This does not change the priority list. It extends it.
| The system offers | Use | Why |
|---|---|---|
| An MCP server | MCP | One interface, every agent reuses it — vet it first |
| A documented API | Wrap it as an MCP server | Auth written once, inherited by every future agent |
| A platform connector, linear flow | The connector | Cheapest thing that works |
| A database or export file | Read it | Reads answer most questions |
| Nothing | Browser agent | The only remaining surface |
A browser step is slower than an API call, costs more per run, and is the thing most likely to break when a vendor redesigns. Reach for it fifth, not first. The right pattern in most real deployments is a thin last mile: the agent reads the document, does the matching and the judgment through proper integrations, and the browser step only performs the final entry into the system that has no other door. That's the same staging as connecting a legacy ERP, where screen automation is the fourth bridge and never the first.
What this actually unlocks
Concrete, from deployments:
- Supplier portal pulls. Log in, read open orders or download the statement, hand the data to the agent that was already doing the invoice matching.
- Web-only internal apps. The 2014 admin tool nobody will rebuild. It has a login and a form; that's enough.
- Recurring form filing. Same fields, different values, every week. The agent reads the source of truth through an API and enters it through the screen.
- Portal-based order entry. A distributor's B2B storefront where orders arrive by email or WhatsApp and get keyed in by hand — the order entry problem with the last 20 percent finally reachable.
- Checks in systems with no report. "Is this shipment marked delivered?" answered from the carrier's site rather than from someone's memory.
None of these are impressive demos. All of them are jobs someone currently does with a browser and a second monitor.
Getting started
- Install Oido Browser Connector from the Chrome Web Store. Any Chromium browser works — Chrome, Brave, Edge.
- In Studio, open Settings → Connected Browser and generate a connector token.
- Open the extension's options. Paste the base URL and token, and add the origins you want to allow, one per line. Save and reconnect; the status should read
connected. - Ask an agent to do something on one of those sites, and watch it work in the tab it opens.
Current v1 limits, stated plainly: one Connected Browser per user, one task at a time, and DOM-based actions only — no vision fallback yet. If a task legitimately spans two origins, add both to the allowlist.
The takeaway
The reason so many automation projects stop at 80 percent is that the last 20 percent lives behind a login on a site with no API. Every guide tells you to solve it with an API that doesn't exist.
The honest answer is that some work has to happen on the screen — so make that step small, scoped to one site, visible while it runs, and gated before it commits to anything. Then it stops being the reason the project stalled.
Want to know which of your processes are stuck on a portal with no API? That's usually the first thing we find — see how the platform connects.
Frequently asked questions
How do you automate a website that has no API?
Four options, in order of preference: a database or file export if one exists, an unofficial or partner API, a scripted browser flow, or an AI agent driving a real browser session. The last one is the only one that works when the site requires a login, changes its layout, or needs judgment about what it's looking at.
What is the difference between a browser agent and a scraper?
A scraper follows a fixed script against a fixed page structure and breaks when the page changes. A browser agent reads the page, decides which control to use, and adapts. The trade is speed and cost: a scraper is cheaper per run, an agent survives the redesign.
Does the agent need my password for the site?
No. The Oido Browser Connector runs inside the Chrome you are already signed in to, so the agent works in your existing session. No site password is ever transferred to or stored by Oido. Anything asking you to hand over site credentials so its cloud can log in as you is a materially worse security model.
Can the agent read my other tabs?
No. It opens a tab of its own, grouped and labelled OIDO, and works only there. The extension requests no `tabs` permission, does not run on the pages you visit, and closes its tab two minutes after the last action.
What stops the agent wandering off to a different site?
Two separate controls. An allowlist decides which origins it may ever reach. A per-task origin-lock pins each task to the site it started on and refuses navigation off it, enforced in the extension rather than by the model — so a hostile page telling the agent to go somewhere else and act simply fails.
When should I not use a browser agent?
Whenever an API or MCP server exists. A browser step is slower, costs more per run, and breaks when a layout changes. Use it for the work that has no other surface, and keep it to the last mile rather than the whole workflow.
How do I set it up?
Install the Oido Browser Connector from the Chrome Web Store, generate a connector token in Studio under Settings then Connected Browser, paste it into the extension's options, and list the sites you want to allow. Then ask an agent to do something on one of them.