RPA or API integration: which is the best choice?

Choose an integration if the system that the data must go to has a usable, documented API: it is usually more stable, faster and easier to monitor than a software robot. Choose a software robot (RPA) if there is no API, if API access is too expensive or comes too late, or if you need the solution only for a while. A combination is often best: an integration where possible and a robot only for the step with no other entry point. And sometimes a simple exchange of files is enough.

What a software robot does, and what an integration does

A software robot works through the screen, like an employee. It opens the ERP package (the business system for orders and administration), logs in, looks up the customer, fills in the fields and clicks Save. The ERP sees no difference from a person: the robot gets the same checks and alerts. This is called RPA (robotic process automation). The robot follows fixed rules and does not think for itself. A software robot is not an industrial robot: it works only in software, not on the shop floor.

An integration lets systems exchange data directly, without a screen. This usually goes through an API (application programming interface): a fixed entry point that the supplier of a system offers for other software. For example, the integration sends the message "create this sales order, with these lines", and the ERP replies with an order number or an error message.

So the robot uses the entry point for people, and the integration uses the entry point for software. In the licensing documentation of Power Automate, Microsoft writes that RPA is needed for applications without a ready-made connector and without an API that you can use to build one yourself. The robot is the route for when the direct way is missing.

The example: orders from email into the ERP

Worked example of order processing (assumptions: 80 orders of 4 minutes, 230 working days, 15% exceptions, 15 minutes of checking per day)
Item	Per day	Per year
Manual work now: 80 × 4 minutes	320 minutes	approx. 1,227 hours
Exceptions stay manual work: 12 × 4 minutes	−48 minutes	approx. −184 hours
Daily check of the automation	−15 minutes	approx. −58 hours
Time actually freed up	257 minutes	approx. 985 hours

The full 320 minutes never count as savings, because the exceptions and the check stay work for people. Development, licences and maintenance are costs that you calculate separately; see what it costs to automate a business process. Important for the choice: a robot and an integration free up about the same time. The difference is in the costs, the maintenance and how often the solution stops.

The comparison on eleven points

The table gives our assessment per point. The reasoning, with sources, is in the sections below it.

Software robot and integration compared
Criterion	Software robot (RPA)	Integration (API)
Availability of an API	Not needed: works with any screen that an employee can access	Needed: a documented API that can both read and write the right data
Development costs	Often lower at the start, because the supplier does not need to cooperate	Low with good documentation, higher with little documentation or an extra module
Maintenance	Higher: a screen change can require an adjustment and a new test	Lower: mainly with a new API version or changed fields
Reliability	Depends on screens, loading times, window size and screen resolution	Usually higher: a fixed agreement between systems, but within the limits of the API
Error handling	The robot must see for itself that something went wrong	The system returns a status or error code for each request
Data quality	The same field checks as for a person; risk of input in the wrong field	The system rejects invalid fields with an alert; which checks the API does differs per package
Scalability	As fast as the screens; more volume requires more robots and licences	Much faster per order, within the limits of the API
Security	A user account with all the rights that this account has in the screens	Its own access key, often with rights per component
Changing applications	Sensitive: an update of the screen can make the robot get stuck	Less sensitive: an API is an agreement with other software, often with version numbers
Complexity of exceptions	Must handle both exceptions in the process and screen problems	Must handle exceptions in the process; technical errors are clearer
Future extensions	Each extra step is extra screen work and maintenance	New data or alerts are usually easier to add

Availability of an API

"There is an API" does not yet mean that the API can do what you need. Check three things. Can the API both read and write the data that your process needs, for example create a sales order with lines, or a bill of materials (BOM: the parts of a product) with the right revision? Is API access included in your subscription, or does the supplier ask for a module, licence or partner programme for it? And can the system be reached? An ERP on your own server needs a secure connection for software from outside. Customer portals and supplier portals do not always have an API that you are allowed to use; then the screen stays the only entry point.

Development costs and maintenance

A robot can start quickly, because you need nothing from the supplier. Against that are ongoing costs: a licence per robot that runs at the same time, a machine and more hours of management. With Power Automate, for example, one Process licence gives one unattended robot (unattended RPA), which runs one desktop flow (an automation that operates screens) at a time. An unattended robot starts automatically and does the work without an employee having to be present. It follows predefined rules. On an error or exception it can stop, send an alert or put the case to an employee. The run stays traceable. The opposite is an attended robot, which an employee starts on their own computer (attended RPA). An integration sometimes needs more work up front. It also has ongoing costs, such as management and sometimes an API module from the supplier, but these are usually lower. Also read what maintaining a software robot costs.

Reliability and changing applications

A robot recognises a field or button by attributes of the screen. UiPath calls such a description a selector. The UiPath documentation calls the position on the screen unreliable, and an attribute that changes at every start makes the element impossible to find. Microsoft warns that an unattended robot in Power Automate can get a different screen resolution than during development. Then it does not find an element, or it even operates the wrong one. So every update of a system that the robot operates is a moment to test.

A documented API is an agreement between the supplier and other software. A screen is made for people, and the supplier is free to change it. An API also changes, but suppliers often use version numbers for this, such as the v2.0 in the Business Central API.

Error handling and exceptions

An API returns a status code for each request. For example, Microsoft Dynamics 365 Business Central returns error code 429 (Too Many Requests) when there are too many requests, and Microsoft writes that the integration must then wait and try again. A robot must work out for itself that something went wrong, for example because an expected screen does not appear. It also gets problems that have nothing to do with the process: an update of the application, a different window size, a screen that loads more slowly than expected. Microsoft names such causes and advises, among other things, longer wait times and a new attempt after an error.

Exceptions in the process, such as an unknown item, are not solved automatically by either of them. You set rules: what does the automation process itself, and what goes to a person? You can read how this often goes wrong in why RPA projects fail.

Data quality

The ERP checks whether something is technically allowed, not whether it is correct. An order with a wrong price is simply valid for the ERP, with a robot and with an integration. So build in your own checks: does the customer exist, is the price within a margin, and has this customer order number not already been processed? That last check prevents a duplicate order if the automation stops halfway and starts again. Also let a robot read back what is in the system after it saves.

Scalability

Suppose the robot needs 2 minutes per order through the screens (an assumption; measure it in your own system). With 80 orders, that is 160 minutes of robot time per day: one robot can easily handle that. With 800 orders per day, it is 1,600 minutes. A day has 1,440, so then you need a second robot, with a second licence and machine.

An integration needs a few requests per order. Business Central online accepts a maximum of 6,000 requests per user within five minutes. 800 orders per day stay well below that. Other packages have other limits; look up the limits of your package.

Security

An unattended robot logs in by itself, on a Windows machine and in the applications. Give it its own account with only the rights that the process needs, and keep the passwords in the vault of the robot platform. Two-step verification makes unattended login difficult; agree with your IT administrator on a solution that the supplier supports. An integration gets its own access key, which you can often limit to certain components. In AFAS, for example, you set in the AppConnector which connectors a token (the access key) may use.

Future extensions

Some APIs send a message by themselves as soon as something changes (a webhook), so the integration does not have to keep checking. Microsoft also recommends this for Business Central. With a robot, every extra step is extra screen work. If you still choose a robot, keep the business rules separate from the screen steps. Then later you replace only the part that enters data.

Options other than a robot or an API

Exchanging files. One system prepares a file in a fixed layout, for example CSV or XML, and the other reads it in. This can go through a shared folder or through SFTP, a secure way to send files between servers. This route does not depend on screens and suits batches, such as a price list. But you see errors only in the import report, and you make agreements about the separator, the date format and the decimal separator. More about this in Connecting Excel to ERP.
A standard connector or workflow tool. For many combinations, a ready-made integration exists: in the app marketplace of your ERP supplier, as a connector in Power Automate, or in UiPath Integration Service. Such a connector is quick to set up, and the supplier keeps it up to date. But the field mapping is fixed, and it often does not know your exceptions. Ask in advance what happens to an order that does not fit.
An integration and a robot together. For example, the robot collects orders from the supplier portal of a large customer without an API, and an integration puts them into the ERP. If the customer later offers an export or API, you replace only the robot part.

All approaches side by side
Approach	Strong in	Limitations
Keep the manual work	Few cases, a lot of judgement per case	Costs time every day, error-prone as volume grows
Exchange files	Batches, systems with import and export	Not immediate, errors only show in the import report
Standard connector	Common combinations without special rules	Fixed field mapping, does not know your exceptions
Integration through an API	Daily flows, large numbers, fast feedback	Needs a usable API and someone who builds and manages it
Software robot	Systems and portals with no other entry point	Sensitive to screen changes, more maintenance
Integration and robot together	Chains in which one system has no API	Two technologies to manage

When a software robot is not a wise choice

There is a usable API or standard connector. A robot is then a detour with more maintenance.
The volume is high or time is tight. Processing more at the same time means more robots, licences and machines.
The screens change often. A web application with a new version every few weeks means testing again and again.
Automatic login is not possible or not allowed. Think of a CAPTCHA, or terms of use of a portal that forbid automated access.
Two systems must always have the same data, such as stock, prices, or items and BOMs in the PDM system (drawing management) and the ERP. An integration fits better there.
The process itself is the problem. A robot makes a cumbersome process faster, not better.
Nobody is the owner. Then the robot can stop at the first screen change without anyone noticing.

Also be careful if the robot sees an application only as an image, for example through a remote desktop. It then works with image recognition or screen coordinates, and a window that has moved can be enough to make it miss. You can read more warning signs in when it is better not to automate a process.

When an API integration is not the best choice

There is no API, or the API lacks the function. Sometimes the API can only read, or the field that you need is missing.
API access costs too much. Compare the costs of an extra module or licence with the licence and maintenance of a robot over a few years.
API access comes too late. A project with the supplier can take a long time, while the manual work costs time now. A robot can bridge that period.
The situation is temporary. If the system will be replaced within a year, an integration rarely pays off.
There are only a few cases. With a few orders per week, an integration often does not pay off, and neither does a robot. Do the sums with the method for calculating the return.

Decision tree

Go through these questions in order for each process step. Stop at the first question that gives a clear answer.

Is the step necessary? No: remove the step or change the process.
Does one of the systems have a standard function or connector that does this exchange, including your exceptions? Yes: use it.
Does the target system have a documented API that can read and write the data, at an acceptable cost? Yes: choose an integration.
Can both systems export and import a file in a fixed layout, and is processing in batches fast enough? Yes: exchange files.
Is there only a screen, and is it stable? Stable means: no new version every few weeks, no CAPTCHA and a dedicated account for the robot. Yes: choose a software robot.
Is there only a screen, but does it change often or does it block automated access? Ask the supplier or customer for an export or API, or keep this step manual.

Two extra questions apply to every route. Do many cases need a judgement on the content that you cannot capture in fixed rules? Then first record the rules where you can, and leave the rest with an employee. Is the robot temporary? Then decide now when you will switch.

What weighs most and what you ask internally

What the target system offers (API, import or connector) usually already decides the choice. After that, these weigh most: how often the screens change, the volume in a few years, how long the solution must last and who manages it. Ask these questions internally:

Do our ERP and our PDM have an API or import function, and is it included in our subscription? Ask the supplier.
How many cases per day are there now, and in three years?
How often do the ERP and the portals get an update?
Will one of the systems be replaced within two years?
Who handles the exceptions, and who sees an alert if something goes wrong?

When outside help makes sense

You can often set up a simple import or standard connector yourself. Outside help makes sense if the API documentation is unclear, if more than two systems are involved, if an error costs money directly, or if nobody internally can maintain the solution. Then choose someone who builds both integrations and robots, so the technology is not fixed in advance. If you first want to check for yourself whether your process is suitable, go through the four questions on the services page: four short questions, without a tool or a calculation. You can read more about integrations on the same page, under ERP integrations.

The example through the decision tree

Example (illustrative)

The same order process in three situations. Only the ERP differs.

The ERP has a documented API for sales orders. Question 3: an integration creates the approved orders, and the ERP replies with an order number or an error message. A robot is not needed.
No API, but an import function for orders. Question 4: every hour, the automation puts the approved orders in an import file. Someone reads the import report. Orders are not in the ERP immediately, but within the hour.
No API and no usable import, but stable screens. Question 5: a software robot enters the orders with its own account and reads back the order number. After each ERP update, the administrator tests the robot.

In all three, the 12 orders with an exception per day go to a review queue for the inside sales team: the list of cases that an employee reviews. About 257 minutes per day are freed up. What differs are the costs, the maintenance and how often something stops. You can read how the whole order process works in automating manual order processing.

Conclusion

The real question is not "RPA or API", but: which entry point does each system offer, and how long must the solution last? An integration is the default choice where there is a usable API. A robot is a deliberate choice for the step with no other entry point, with an owner and a test after every update. The technology hardly changes the time freed up, but it does determine the costs and how often you get surprised. If you then need to choose a platform, read UiPath or Power Automate.