RPA or API integration: when screen automation becomes debt

Robotic process automation gets a bad reputation it half deserves. The technology is fine. The problem is that it is usually chosen for the wrong reason: it is the fastest thing to demo, and it does not require anyone else's cooperation.

That second property is the real appeal. An API integration needs the vendor to have an API, needs procurement to approve access, and needs someone on the other side to answer email. A bot driving the UI needs none of that. You can ship in two weeks without asking permission.

Then the vendor moves a button.

What you are actually choosing between

The distinction that matters is not "bot versus API". It is which contract you are depending on.

An API integration depends on a contract the vendor publishes, versions, and is embarrassed to break. Screen automation depends on the layout of a page, which is not a contract at all. It is an implementation detail that the vendor changes without telling anyone, because from their side, nothing broke.

Everything else follows from that.

Situation	Choose	Reasoning
Vendor has a documented API	API	The bot saves weeks now and costs them back every release.
Vendor has an API but access is blocked internally	API, after escalating	This is a procurement problem. Solving it with a bot makes it permanent.
No API, vendor is being replaced within a year	RPA	Correct use of a disposable tool. Set the retirement date in writing.
No API, system is strategic and staying	Neither yet	You need a real integration path: file exchange, database read replica, or vendor pressure.
Internal legacy app, source available	API	Adding one endpoint is usually cheaper than maintaining a bot for a year.
Process spans 5+ screens with human judgment	Neither	Automating a bad process makes it faster, not better. Redesign first.

The cost that does not appear in the estimate

An RPA estimate covers building the bot. It rarely covers what the bot costs to keep alive.

• Every vendor UI release is a potential outage, and you find out from a failed run, not a changelog.
• The bot needs credentials that a human normally uses, which means a service account with a real person's permissions, or worse, a real person's password.
• Failures are silent by default. A bot that clicks the wrong thing does not throw an exception. It completes successfully and does something wrong.
• It only runs where a session exists. Multi-factor authentication, session timeouts, and IP restrictions all become operational chores.

None of these are reasons never to use RPA. They are reasons to price it as an ongoing operational commitment rather than a project.

If RPA is the only option

Sometimes it genuinely is. In that case, four practices separate a bot you can live with from one that becomes a liability.

Assert on outcomes, not on steps. After the bot finishes, verify the result independently: query the record, check the total, confirm the status changed. A bot that only knows "I clicked the things" cannot tell you it failed.

Make every run idempotent and resumable. Bots get killed mid-process constantly: session timeouts, browser crashes, machine restarts. A run that cannot safely be repeated turns every interruption into manual cleanup.

Give it its own identity. A dedicated service account, with only the permissions the process needs, and credentials in a secret store rather than in the automation script. This matters for audit as much as security, and it is part of what we cover in our security practices.

Set a review date, not a retirement hope. Put a calendar entry six months out that asks one question: does this vendor have an API now? Bots outlive their justification because nobody ever revisits the decision.

Where AI changes the picture, and where it does not

Vision-based automation that "understands" the screen is genuinely better at surviving small layout changes than selector-based scripting. That is a real improvement to a real problem.

It does not change the underlying issue. You are still depending on a presentation layer instead of a contract, and you have added a component whose behavior is probabilistic. A bot that is 97% right on a financial process is not 97% good. It is a system that produces wrong records at a steady rate, and now the wrong records are harder to predict.

If you do put a model in an operational loop, the confidence threshold and the human review path matter more than the model, which is the subject of running an LLM in production.

The honest summary

RPA is a correct answer when the target system has no interface and a known end date. It is a bad answer when it is chosen to avoid a conversation with a vendor or another team, because the bot then becomes permanent and the conversation never happens. That judgement call is part of what we work through on AI and automation engagements.

If you are moving data rather than driving a UI, the question is a different one: see ETL versus ELT.