Bots on the screen or calls to the API: where RPA earns its place and where it becomes debt

RPA automates a system through the interface built for people. API integration automates it through an interface built for software. The first is faster to start and more expensive to keep. Screen automation is a reasonable tool when there is truly no other door into a system, and it turns into debt the moment it becomes a permanent substitute for an integration you could have built.

Two layers, one job

Both approaches exist to move data between systems and trigger actions without a person retyping things. They differ in which layer of the target system they touch.

An RPA bot logs in as a user would. It opens a screen, finds a field by its position, label or underlying element, types a value, clicks a button and reads what appears. It depends on everything a human depends on: the layout, the order of screens, the session, the pop-ups.

An API integration sends a structured request to an endpoint the vendor has published and receives a structured response. It depends on a contract: these fields, these types, these error codes, this version.

That difference in what each one depends on explains almost everything else.

The last three rows are why RPA gets chosen. The first five are why it gets regretted.

The cost that is missing from the estimate

An RPA proposal usually prices the build: so many processes, so many days each. The build is the small part. The costs that arrive later look like this.

Breakage from changes you do not control. The SaaS vendor ships a redesigned form. The ERP gets a patch that adds a confirmation dialog. A browser update changes how an element renders. IT pushes a new screen resolution or a security banner. The bot was not consulted about any of these, and each one can stop it or, worse, misdirect it.

Silent wrong results. A failed API call tells you it failed. A bot that typed the amount into the reference field because the form gained a new row may complete "successfully" hundreds of times before anyone notices. The cost of a quiet error is the cleanup plus every decision made on the bad data.

Exceptions that return to people. A bot handles the path it was recorded on. The customer with two accounts, the invoice in a foreign currency, the record locked by another user all fall out to a manual queue. If that queue is thirty percent of the volume, you have automated the easy seventy percent and kept the team that handles the hard part, now with less context.

Infrastructure and licenses. Bots need machines or virtual desktops to run on, a scheduler, an orchestrator and, with commercial platforms, licenses that are often priced per bot or per runtime. These are recurring costs that sit outside the original business case.

Credentials and audit. A bot needs a login. It is tempting to give it a real employee's account or a shared one. Then the audit log says a person did things a script did, multi-factor authentication becomes an obstacle to work around, and password rotation breaks production on a schedule.

The frozen process. This is the least visible cost. Once forty bots depend on the exact screens of a system, upgrading that system means retesting and repairing forty bots. Modernization gets postponed because the automation built to cope with the old system has made it more expensive to leave.

A rough test for whether a bot has become debt: add up the hours spent each month repairing and babysitting it, and compare that with the hours it saves. Many teams have never done this sum for their oldest bots.

A decision order that holds up

Before choosing screen automation, go through the alternatives in order. Stop at the first one that works.

1. A documented API. Check current vendor documentation, not memory. Many systems that had no API five years ago have one now, sometimes on a higher license tier that is still cheaper than a bot farm.
2. Webhooks or events the system can emit when something changes.
3. A supported bulk interface: scheduled export, import file, SFTP drop, EDI.
4. A database interface the vendor supports, such as a reporting replica or a staging table that the application itself validates and processes.
5. An integration platform connector that someone else maintains against the vendor's API.
6. Asking the vendor or the other party. A partner portal with no API sometimes has one for customers who ask, or will send a daily file.
7. Screen automation. When all of the above are closed.

There are legitimate cases at step 7. A mainframe terminal application with no service layer. A government or insurer portal that offers only a web form. A desktop application whose vendor no longer exists. A partner's system you have no leverage over. A process that will be retired in six months, where a proper integration would never pay back.

There is also a legitimate tactical use: a bot as a bridge. You need relief this quarter and the real integration will take two. That is fine, provided the bridge has an end date written down and an owner for the replacement.

If the screen is your only door

When RPA is the right answer, build it as if it were production software, because it is.

• Wrap it behind an interface. The rest of your systems should call something like submitClaim(claim) and receive a result. They should not know a bot is involved. When an API becomes available, you replace the inside and nothing else changes.
• Never let the bot borrow a person's login. Create a service account used by nothing else, grant it the minimum access the process requires, hold its credentials in a secrets vault, and make sure the audit log can tell its activity apart from human activity. Check the target system's terms of use: some prohibit automated access.
• Anchor on stable things. Prefer element identifiers and accessibility labels to screen coordinates and image matching. Coordinates are the first thing a redesign breaks.
• Verify after every write. Do not assume the click worked. Read the record back and compare it with what you intended to enter. This single habit converts most silent failures into loud ones.
• Make each item restartable. Work from a queue. Record the state of every item (pending, in progress, done, failed with reason). A crashed run should resume without creating duplicates, which means checking whether the item already exists before entering it.
• Design the exception path first. Decide where unhandled cases go, who works them and how fast. Capture a screenshot and the data at the point of failure so a person can pick it up without starting over.
• Monitor like a service. Alert on failure, on unusually long run times and on unusual volumes, including zero. A bot that processed nothing and reported success is a common Monday morning discovery.
• Run a canary. A small scheduled check that logs in and confirms key screens look as expected will catch a UI change before the nightly batch does.
• Keep the scripts in version control, with a test environment if the target system offers one, and one named owner per bot.
• Write the exit condition. "Retire when the vendor releases the claims API" or "retire when system X is replaced". Review it twice a year.

What AI changes, and what it leaves alone

Language and vision models have changed part of this picture, and it helps to be precise about which part.

Where they help. A large share of bot failures used to come from unstructured input: an invoice PDF in a new layout, an email written by a person, a scanned form. Models are good at turning that into structured fields, which is the step that rigid templates handled worst. Models can also locate an element on a screen by what it is ("the Submit button") instead of where it is, which makes automation less sensitive to cosmetic changes. And they speed up the writing of integration code and mappings, which lowers the cost of doing the API work properly.

Where nothing has changed. A model that drives a user interface still depends on that interface. It is slower and more expensive per step than a script, and it is not deterministic: the same screen can produce a different action on a different run. A deterministic bot that breaks stops. A model-driven agent that is confused may keep going, plausibly and wrongly. For work that has to be done the same way ten thousand times, that is the wrong property.

It also does not make a user interface transactional, does not remove rate limits or terms of use, and does not produce a contract where the vendor has not published one.

The combination that works in practice: use a model to read and classify the messy input, attach a confidence measure, send low-confidence cases to a person, and let deterministic code (an API call where possible, a scripted bot where not) perform the action. Keep the judgment and the execution in separate components so each can be tested on its own.

The short version

• If an API, event or supported file interface exists, use it. It costs more in the first month and less every month after.
• If none exists, RPA is a valid tool. Treat it as software: isolated behind an interface, verified, monitored, owned.
• If RPA is a stopgap, give it an end date and fund the replacement.
• A fleet of bots around an old system is a reason to modernize that system, not a way to avoid it.
• AI improves the reading of unstructured input. It does not turn a screen into a contract.

Is your automation saving time, or just moving the work to whoever fixes the bots?

If you are not sure, that is worth measuring before the next bot gets built. Trivo can inventory your automations, sort the bots that could be replaced by a proper integration from the ones that should stay as they are, and give you a written plan with the costs side by side.