Everything Has a UI. Almost Nothing Has an API.

The tab you cannot script

Make a list of the software your team touched this week. Now cross off everything you can drive from code without asking anyone's permission. On most teams the second list is a third of the length of the first, and the things that survive are the ones somebody already integrated years ago.

What is left on the first list is not exotic. It is the video tool your designer pays for. It is the seller console where your listings live. It is the supplier portal that emails you a PDF once a month. It is the recruiting seat, the claims portal, the customs filing system, the internal app whose owning team has long since dispersed. Every one of them is a product you already pay for and are already authorised to use. And every one of them can only be operated by a person, with a mouse, in a tab.

This is the gap that people keep asking us to close, and the questions arrive with a striking sameness. Not "how do I scrape this site" - almost nobody asks that any more. The question is "I have an account here, I do this same thing forty times a week, why can I not call it".

Three ways a product ends up unreachable

It is worth separating the causes, because they have different shapes and different half-lives.

There is no API. The vendor shipped a web app and stopped. Google's Flow, its filmmaking tool, is the example everyone reaches for right now: no public API, a queue of developers asking for one on Google's own forums, and a small industry of third-party wrappers that have appeared to sell what Google does not. Midjourney has been in this position for years - it has never shipped an official API, its terms prohibit automated access, and every product marketed as a "Midjourney API" is an unofficial wrapper built on the interface. Suno is the same story in audio. This is not confined to generative AI; it is simply where the pain is loudest, because the users are technical and the tasks are repetitive by nature.

The API is a different product from the thing you bought. This one surprises people the most. A consumer subscription and a developer API are frequently two separate businesses inside the same company, with separate balances that do not convert. Buying the top consumer tier of a video model and then discovering that none of those credits can be spent through the API is now such a common confusion that vendors write it into their FAQs. Worse, the metered developer rate is often several times what the same generation costs you as a subscriber. So the customer's rational move - use the seat I already bought - is the one move the product does not support.

The API exists, but not for you. Access review. A partner agreement. A minimum spend. A developer token that takes a quarter of correspondence. A quota structured for an integrator rather than a customer. Recruiting products, large advertising platforms and most financial portals sit here. The irony is sharp: you are permitted to see every one of these records with your own eyes, right now, in a browser, and forbidden to fetch the same record programmatically.

Notice what all three have in common. In none of them are you trying to get at data you have no right to. You hold the seat. The obstacle is the shape of the door.

Where the demand actually is

We keep a list of what people ask us to point automation at. It is longer and stranger than the "AI tools" framing suggests, and the long tail is where most of the working hours are.

Category	Names that come up	What people want to call
Generative media seats	Google Flow, Midjourney, Suno, Runway, Kling, Luma, Higgsfield, Leonardo, Krea, Freepik	Generate, iterate, download, catalogue
Assistant and research seats	NotebookLM, Google AI Studio, Perplexity, Grok, Gemini, Copilot	Ask, collect, export, keep a corpus in sync
Marketplace seller consoles	Amazon Seller Central, Walmart Seller Center, eBay, Etsy, TikTok Shop, Shopee, Lazada, Mercado Libre, Allegro, Alibaba, Temu	Listing edits, order exports, dispute queues, buy-box checks
Advertising consoles	Google Ads, Meta Ads Manager, TikTok Ads, Amazon Ads, LinkedIn Campaign Manager, Reddit Ads, Snapchat Ads	Pull spend, push budgets and bids, export reports
Social and creator accounts	LinkedIn, X, Instagram, TikTok, YouTube Studio, Pinterest, Threads, Reddit	Post, schedule, read the inbox, pull your own analytics
Recruiting and sourcing	LinkedIn Recruiter, Indeed, ZipRecruiter, Workday, Greenhouse, Lever, SmartRecruiters	Saved searches, pipeline state, message history
Procurement and supplier portals	SAP Ariba, Coupa, Jaggaer, Tungsten, Taulia, SAP Concur, Basware	Invoices, purchase orders, statements, remittance advice
HR and payroll administration	ADP, Paychex, Gusto, Rippling, Deel, Workday	Headcount exports, pay runs, document retrieval
Insurance and claims	Carrier portals, clearinghouse portals, broker back-offices	Eligibility, claim status, remittance downloads
Government and compliance	Tax authority portals, customs filing, company registries, trademark and patent offices, public tender portals	File, check status, download the receipt
Logistics and carriers	FedEx, UPS, DHL, Maersk, LTL carrier portals, forwarder extranets	Rates, bookings, tracking exceptions, proof of delivery
Travel and hospitality extranets	Booking.com Extranet, Expedia Partner Central, Airbnb, Agoda, channel manager back-offices	Rates, availability, inventory, reviews
Analytics and research seats	Semrush, Ahrefs, Similarweb, Search Console, App Store Connect, Google Play Console	Export the numbers the seat already shows you
Internal legacy applications	In-house admin tools, vendor systems with a paid API tier, intranet workflows	Everything

Read that as a demand list, not a scoreboard. Several of those publish an API, and the reason they still come up is cost, coverage or an access review rather than absence. A few have none at all today - Google Flow, Midjourney, Suno and the consumer NotebookLM are the ones asked about most often - and any of it can change on the vendor's schedule rather than yours.

Two things stand out when you look at this as one list rather than thirteen.

The first is that the most valuable items are almost never public data. They are your own records, behind your own login. That is a different problem from web scraping, with different mechanics and a different risk profile, and it is the reason generic scraping infrastructure does not solve it.

The second is that an enormous fraction of the world's business process is still, in 2026, a person filling in a form. The portals are not going away. The APIs are not arriving. Something has to sit between them.

How the industry answers this today

There are four families of answer in the market, and each of them is genuinely good at something.

Classic RPA. The oldest answer and still the biggest business. A bot drives the interface, usually on a virtual machine somebody in IT maintains. It works, it has two decades of enterprise governance behind it, and it is the right tool when the process is stable and lives inside a company that will fund a centre of excellence for it. It is a poor fit for one developer with one seat and a script, and its selector-based recorders are famously brittle when a vendor ships a redesign.

Third-party unofficial wrappers. Someone else builds the automation and rents it to you as a REST endpoint. This is the entire Midjourney-API and Flow-API cottage industry. It is fast to adopt and it removes all the operational work, but look closely at what you are agreeing to. Either you hand over your credentials so the vendor can drive your account, or the vendor drives its own farm of accounts and you are buying output from an identity you know nothing about. In the first case your account risk is now in somebody else's hands. In the second, the terms-of-service exposure is real but invisible, and the service disappears the week the upstream site changes.

Cloud browser infrastructure with saved authentication. The current wave, and technically the most interesting one. Browserbase has Contexts, Browser Use has profiles that can even import your real Chrome profile, Kernel offers managed auth that will discover credentials and handle a TOTP code, Anchor and Airtop and Notte each ship their own flavour of a saved identity. Underneath, these are all the same primitive: a persisted browser user-data directory that survives between sessions, so the agent does not log in every run. It is the right primitive. What it does not settle is everything downstream of "the cookie is still there" - which, as we will get to, is most of the difficulty.

Agents that simply look at the screen. Give a model a browser and a goal. Extraordinarily flexible, and the only thing that works on a portal nobody has ever automated before. It is also slow, expensive per run, and non-deterministic in a way that matters: if you are calling the same operation four hundred times a day and feeding the result into a database, you need the same schema every time, and a model deciding afresh each run what "the result" means is not that. The pragmatic pattern the market has converged on is to use the model once, at authoring time, to produce a deterministic script, and keep it out of the hot path afterwards.

The hard part is not clicking. It is staying the same person.

Every one of those four families is good at making a click happen. The failures almost never come from the click.

Sessions expire, and how they expire is the whole game. A cookie jar copied at nine in the morning may be a valid session at noon and a login wall at midnight. Refresh flows differ per site. Some issue short-lived tokens that renew silently; some require a full re-authentication; a growing number bind the session to a key held by the device's secure hardware, which by design cannot be copied to another machine at all. An automation layer that treats authentication as "we saved the cookies" will work in the demo and fail in the third week.

The account has a history, and the risk engine remembers it. This is the part that generic browser infrastructure leaves entirely to you. An account that has signed in from the same laptop in the same city for two years, and then makes an API-driven request from a fresh headless browser in a datacentre, has not just changed device - it has produced the exact signal that fraud systems are built to catch. The result is not usually a clean error. It is a verification challenge, a temporary lock, a request for a code sent to a phone, or a silently degraded experience where the page renders but the button does nothing. Debugging that from a log line is miserable, because from the automation's point of view it simply clicked and nothing happened.

Two machines will diverge. Once the same account is driven from a laptop by hand and from a runner by script, you have two copies of a session and no merge strategy. The last one to close wins, and whatever the other one wrote is gone. Most teams discover this after it eats a day's work.

Some steps genuinely need a human. A payment confirmation, a one-time code, a legal acceptance, a CAPTCHA that a given site has every right to show you. A design that cannot hand the session back to a person at that moment is a design that fails permanently at the first such step, rather than pausing.

Concurrency is not a knob you can turn freely. Ten parallel calls against one seat looks nothing like a human using that seat, and plenty of products are watching for exactly that.

Read that list again and notice what it is describing. It is not an automation problem. It is an identity problem. The click is the last ten percent.

What a UI-to-API layer has to get right

If you are evaluating one, or building one, these are the properties that decide whether it survives contact with production.

1. It drives your account, not a stranger's. You sign in yourself. The layer never needs your password, because it reuses the session you created. Nobody else stores your credentials and nobody else's accounts are quietly substituted for yours.
2. The identity persists and stays coherent. Not just cookies - the whole environment. Same device characteristics, same network exit, same locale and timezone, every call, matching the way that account has always been used.
3. The model is off the hot path. Use it to author and to repair. Do not put it between the caller and the result, or you inherit its latency, its cost and its variance on every single call.
4. Actions are named, versioned and typed. generate with a defined input and a defined output. When the site changes, the action's version changes and your code does not, or it breaks loudly at a boundary you can see.
5. Long work is a job, not a held-open connection. Anything that takes minutes returns a handle you poll. A render queue must never be an HTTP request waiting on a socket.
6. Errors name the layer that broke. A login wall, a challenge page, a changed selector and a genuine site error are four different conditions with four different fixes. Collapsing them into one timeout is the single most common way this kind of tooling wastes your afternoon.
7. Idempotency wherever the site permits it. A retried call must not spend your credits twice, place a second order, or send a second message.
8. There is an escape hatch to hands. When a step needs a person, you open the same environment yourself and finish it, then let the automation carry on. This only works if the automated session and the human session are literally the same environment rather than two copies.

Points 1, 2 and 8 are the ones the market is currently weakest on, and they are also the three that a persistent, identity-stable browser profile is unusually well placed to solve - because a profile is already the thing that holds a session, a fingerprint and a network exit together as one object, and it is already the thing a person can open by hand.

Where the line is

None of this is an argument that every site should be automated. Terms of service vary enormously and they are not decoration: some products explicitly permit programmatic use of your own account, some restrict it, and a few will close an account over it. That judgement is per site and it belongs to the account holder, who is the only person with both the contract and the context.

What is worth rejecting is the sloppy version of the argument that runs the other way - the idea that because a vendor did not build an API, anything you do with your own login is illegitimate. Reading your own invoices, exporting your own listings, downloading your own generated files and filing your own returns are not adversarial acts. They are the things you bought the seat to do. The absence of an API is a product decision by the vendor, not a boundary you agreed to.

The honest position is narrow and it is the one we take: drive accounts you hold, on terms you have read, at a rate that looks like the use you are paying for.

The shape of the answer

Every serious attempt at this problem converges on the same substrate. Not a scraper and not a screenshot loop - a durable, identity-stable browser session that a person can also open, plus a small typed contract in front of it. The session is what makes the call possible at all. The contract is what makes the result usable by a program.

That substrate already exists for anyone running profiles: a synced profile is a browser environment with a fixed identity, its own network exit, its own cookie jar and its own passkeys, that follows you between machines and can be opened by hand at any moment. Putting a typed action in front of it is a much shorter distance to travel than building the session layer from scratch, and it is the direction we are taking - we have written up how it works, and what it deliberately will not do, at Profile API.

If there is a specific site you would point it at, that page has a form on it. The list at the top of this article came from people answering exactly that question.