- Automation
RPA or API: the deciding criterion, and why the obvious answer is often wrong
Where an API exists it is almost always preferable. But waiting for an API that will not arrive for eighteen months sometimes costs more than a robot.
· 4 min read · AzerOps
The debate is old and usually badly framed. "RPA is a sticking plaster, build APIs" is an architect's statement. "The API will take eighteen months, build a robot" is an operator's statement. Both are right over different horizons.
What each really costs
An API integration is expensive to set up when the API does not exist: it has to be specified, built on the source system, secured, documented and approved. On a third-party package it assumes the vendor exposes one, which is not a given. Once in place, however, it almost never breaks: an interface contract is stable by construction.
An RPA robot is cheap to set up and expensive to maintain. It depends on the graphical interface, and therefore on things that change without notice: an application update, a moved field, a new warning dialog. Budget fifteen to twenty-five per cent of the build cost per year, every year.
The crossover point generally sits between two and four years. Below that, the robot is cheaper. Beyond it, the API wins.
The decision grid
Build an API if it already exists, or if the source system is yours and exposing it is reasonable, or if the process is strategic and lasting, or if volumes are high.
Build a robot if the target system is a closed package with no programmatic interface, or if the process has a known limited lifespan, or if opening an API depends on a project whose timing you do not control.
Build a robot now and an API later if the need is urgent but lasting. That is a legitimate choice provided it is explicit: the robot is a transition solution, with a planned end date and an API budget on the roadmap. What causes problems is not the temporary robot, it is the temporary robot nobody remembers was temporary.
The hybrid case that works well
On older applications whose source code is available, a third route is often best: expose a thin API over the existing system, without rewriting the application core.
That applies particularly to in-house business applications, where direct access to the database or a service layer allows a clean interface to be built for a fraction of the cost of a robot maintained over five years.
The question to ask your provider
"In which cases do you advise against RPA?" An RPA specialist with no precise answer is selling a tool rather than a solution. A provider who answers "when an API exists or can exist more cheaply" has done the calculation, and you can trust them to do it again on your case.