RPA or API integration – when to use a robot and when to connect systems directly

An API is an official link through which one program passes data to another, without human involvement and without opening any windows. It works like a serving hatch between two kitchens: the order goes in on one side and the dish comes out on the other. The exchange takes a fraction of a second and does not depend on what the application’s screen looks like.

An RPA (robotic process automation) robot works quite differently. It logs in to an application like an employee, opens windows, clicks buttons and types in data. It does not need an API; what a person sees on screen is enough.

Everything else follows from this difference. An API is fast and unaffected by changes in how a program looks, but it has to exist and be available. A robot can cope with any application, but it will stop when the screen it works on changes.

The question “which is faster: an API or a robot?” has no single answer, because API integration in practice covers two different situations. The first is a ready-made connector, a link to a specific application available off the shelf in an automation tool. The second is an API you have to build the connection to yourself. Below are indicative timings for a single simple process, including testing – they may differ in your company.

The summary below shows that integration through a ready-made connector is usually quicker than a robot. A robot sometimes beats integration built from scratch, but in return it needs ongoing care. Count not only the set-up time but also the cost of maintenance over several years.

Choosing a robot in the situations below usually means higher maintenance costs with no benefit. If your process matches any of these points, start with an API.

For example, an online shop and a warehouse system both have APIs. The customer clicks “Order”, and in the same second the warehouse reserves the goods and sends back a confirmation. A robot could not do this at that speed.

A robot is the right choice where integration is impossible, unavailable or not cost-effective. There are more such situations than IT teams used to APIs tend to assume.

We describe in detail how robots work with systems that have no API in a separate guide on automating legacy systems.

It is worth asking these questions separately for each connection between systems. Write down the answers – they will come in handy when, a few years from now, someone asks why a robot or an integration was chosen.

If the answer is “robot”, also write down a condition for revisiting the decision, such as “check the API after the ERP upgrade”. A robot chosen as a temporary fix often stays for good simply because nobody remembered it.

The best results come from choosing the method for each section of the process separately. An automated flow, for example in Power Automate, retrieves data through an API wherever possible and passes it to a robot wherever there is no API.

In such processes, the most important point is where the two meet. Decide what happens when the robot fails to enter the data: who gets notified and how they know which records need fixing. Below are three hypothetical examples.

The most common mistake is one technology for the whole company. An “always API” rule means legacy systems stay unconnected to anything for years. An “always robot” rule leads to robots where a connector would have done.

The second mistake is counting only the set-up cost. A robot can be quicker to get started, but it needs attention after every change in the application. An integration can cost more at the start, but then needs fixing less often.

The third mistake is overlooking licences. Premium connectors in Power Automate require a Premium licence, and a robot working overnight requires a Process licence. Check this before comparing quotes, because this item is easily missed.