RPA vs API Automation: When You Need a Software Robot
If the system you want to automate has an API, automate through the API: it is faster, cheaper to run and much less likely to break. If it has no API, the screens are stable and the task is repetitive and rule-based, a software robot (RPA) is a legitimate fallback, and often the only option. The mistake is reaching for RPA first, because a robot that clicks through screens is the most fragile form of automation there is. It earns its place only where nothing sturdier exists.
This post gives you a decision rule you can apply to any task, a comparison table, what RPA really costs to keep alive, and a worked example.
The decision rule
Ask these questions in order and stop at the first yes.
- Does the app have a documented API (or webhooks)? Use API-based workflow automation. This covers most modern SaaS: CRMs, e-commerce platforms, accounting tools, Google Workspace.
- Can it export or import files on a schedule, or send reports by email? Automate around the file. A scheduled CSV landing in a mailbox or a folder is an integration, even if nobody calls it one.
- Is there a database you are allowed to read? Read it directly, or through a reporting view. This is common with older on-premise software.
- None of the above, but the task is repetitive, rule-based and the screens rarely change? This is the RPA case.
- None of the above, and the task needs judgment or the screens change monthly? Do not automate it with a robot yet. Fix the process or change the vendor first.
Most teams are surprised by how often question 2 or 3 gets a yes. "It has no API" frequently means "nobody checked for the export button".
Where RPA is the right tool
RPA fits a narrow, recognisable set of situations:
- Legacy desktop ERPs and accounting packages with no integration layer, where staff retype data from a sheet into forms every day.
- Supplier, customs, tax and government portals that you log into to download the same report or submit the same form on a schedule.
- Bank portals that offer a manual statement download but no usable API for your account type (check the bank's terms first, and prefer any official API or export).
- Insurer, marketplace or partner back offices that give you a login and nothing else.
- Migration bridges: a temporary robot that moves data between an old system and its replacement while the proper integration is built.
What these have in common is that the human is already acting as the integration. The robot takes over that exact job.
API automation vs RPA, side by side
| API / workflow automation | RPA (software robot) | |
|---|---|---|
| How it works | Systems exchange data directly | A robot operates the screens like a person |
| Speed | Typically a fraction of a second per call | Typically seconds to minutes per task |
| Breaks when | The vendor changes or retires an endpoint (announced, versioned) | A button moves, a field is added, a login page is redesigned (often unannounced) |
| Maintenance | Low, mostly credential and quota changes | Ongoing, expect periodic repairs |
| Error handling | Structured error codes | You have to detect failure by what the screen shows |
| Credentials | API keys or OAuth scopes with limited rights | Often a real user login, which is riskier |
| Runs where | Anywhere, including a hosted workflow engine | Needs a machine or browser session that can open the app |
| Build cost | Usually lower | Usually higher for the same task, because of waits, retries and monitoring |
| Best for | Anything with an API | Systems with no API, stable screens |
What RPA really costs
The build is the visible part. The costs that surprise people come afterwards.
Screens change. Robots find elements by their position, label or HTML structure. When the vendor updates the interface, the robot may fail, or worse, click the wrong thing. You cannot negotiate this away with a vendor who does not know you automate against them.
It needs a place to run. A web portal robot needs a browser session; a desktop robot needs a machine with the application installed and a user session. That machine has to be kept on, patched and logged in.
Credentials are the biggest risk. A robot usually signs in as a person. Use a dedicated account with the least permission the task needs, store secrets in a credential store rather than in a script, a spreadsheet or a chat message, and agree how two-factor prompts are handled. Read the portal's terms of use first, because some services restrict automated access, and prefer an official API or export wherever one exists. That applies doubly to banking.
It needs monitoring. A robot that fails silently is worse than no robot, because people stop checking the numbers. Every run should leave a log line and a failure alert, and key steps should save a screenshot you can look at later.
It is slower to build than it looks. Most of the effort is not the happy path. It is slow page loads, pop-ups, validation errors, session timeouts and duplicate prevention.
A rough rule of thumb, not a benchmark: if the robot saves only an hour or two of staff time per month, expect maintenance to eat the savings.
A worked example (generic)
A small distributor receives purchase orders by email as PDFs. Each week someone reads about a hundred of them and keys the lines into an older desktop ERP that has no API and no import function. It takes roughly a day, and typing errors cause invoicing disputes. (These numbers are an illustration, not a benchmark.)
How the decision rule plays out:
- API? None. Checked with the vendor.
- File import? None.
- Database access? The vendor's licence forbids writing to it directly. Reading would not help here.
- Repetitive, rule-based, stable screens? Yes, the order-entry form has not changed in years.
So the design is a pipeline split into the part that has APIs and the part that does not:
- API side (workflow): the mailbox is watched, PDFs are read, line items are extracted and matched to the product list, and everything lands in a staging sheet with a "needs review" flag for anything uncertain.
- RPA side (robot): for each approved row, the robot opens the order form, types the customer, lines and quantities, saves, and writes the ERP order number back to the sheet.
- Safety net: a person approves low-confidence rows, the robot stops on any unexpected screen and alerts someone, and every order has a screenshot of the saved confirmation.
The robot is only a small part of the system. Everything it does not have to do is done through sturdier means. That is the pattern we recommend: use APIs and files for as much of the job as possible, and keep the robot for the last mile that has no other door.
If you want help judging which of your tasks belong on which side of that line, our n8n workflow automation and RPA service starts with exactly that assessment, and we say so plainly when a robot is the wrong answer.
Where Apps Script and n8n fit
For anything with an API, you have two sound families of tools: a workflow engine such as n8n, or Google Apps Script when the work lives in Google Workspace. We compared them, along with Zapier and Make, in n8n, Zapier, Make vs Apps Script, so we will not repeat that argument here. The relevant point for this post is that both are API-side tools. Neither is built to operate an application that exposes no interface to talk to; that is a robot's job.
Two Apps Script techniques are worth trying before you commission a robot:
- Email as an API. If a system can send a report or notification by email, parse those emails into Google Sheets and you have an integration with no screen automation at all.
- Scheduled triggers. Once data is in a sheet, Apps Script time-driven triggers can validate it, flag exceptions and feed the next step.
Honest caveats
- RPA is not always the cheapest option. If the task takes an hour a month, hire the hour. The case for a robot improves with volume and error cost.
- Some tasks should not be robotised, such as anything needing human judgment, anything where an error moves money irreversibly without review, or portals whose terms forbid it.
- A robot does not fix a bad process. It repeats it faster. Clean up the steps first.
- Vendors may eventually add an API. Ask, because it is cheap to find out. If one appears, migrate and retire the robot.
- We have not benchmarked failure rates across RPA tools, and you should treat anyone's quoted uptime figure for screen automation with caution, because it depends entirely on how often the target interface changes.
A quick checklist before you commission a robot
- I have asked the vendor about an API, webhooks, scheduled exports and bulk import.
- The task is repetitive, rule-based and runs often enough to justify the build.
- The screens have been stable for a long time, or the vendor can warn me of changes.
- I can create a dedicated, least-privilege login for the robot.
- Someone owns monitoring and repairs.
- The terms of the system allow automated access.
If you can tick all six, a robot is a sensible tool. If you cannot, the answer is usually an API, a file import or a process change instead.
Want this scoped for your business?
If you have a portal or a legacy system that someone retypes data into every week, we can tell you in a free 30-minute discovery call whether it needs a robot, a file-based workflow or neither. If it makes sense to build, you get a written plan and quote first. Our n8n workflow automation and RPA page explains how we work, or you can message us on WhatsApp with a one-line description of the task.
Frequently Asked Questions
What is the difference between RPA and API automation?
API automation lets two systems exchange data directly, in a format both sides document and promise to keep stable. RPA (robotic process automation) is a software robot that operates the user interface the way a person would: it opens a window or a web page, clicks, types and reads what is on screen. API automation is faster, cheaper to run and far less fragile. RPA exists for the cases where the system offers no API, or the API does not expose the thing you need.
When should I use RPA instead of an API?
Use RPA only when three things are true: the task is repetitive and rule-based, the system has no usable API or export, and the screens are stable enough that a robot can rely on them. Typical fits are a legacy desktop ERP, a supplier or government portal where you download the same report every week, or a bank portal that only offers a manual download. If an API exists, use it. If a scheduled CSV export or an email feed exists, use that before reaching for a robot.
Can I automate data entry without an API?
Yes, with a software robot that fills the same forms a person would, reading the values from a sheet or database. It works well when the form layout rarely changes and the volume justifies the build. It needs more care than API work: a robot has to handle slow page loads, pop-ups, login expiry and validation errors, and someone has to maintain it when the screens change. Before building one, check whether the application can import a file, because a bulk import is almost always more reliable than a robot typing.
Is RPA fragile?
More than API automation, yes. A robot depends on what the screen looks like, so a renamed button, a new field or a redesigned login page can stop it. Good builds reduce the risk with stable selectors, explicit waits, screenshots and alerts on failure, but they cannot remove it. Plan for maintenance as a normal cost, and prefer an API or file import whenever one is available.
Is it safe to give a robot my login credentials?
It can be, if credentials are handled properly: a dedicated account with the minimum permissions the task needs, secrets kept in a credential store rather than in a script or a spreadsheet, two-factor rules agreed with the portal owner, and a log of what the robot did. Check the portal's terms of use before you start, since some services restrict automated access. Where the portal offers an official API or export, prefer it.
