What Is RPA (Robotic Process Automation)?
Robotic Process Automation (RPA) is a technology that automates repetitive software tasks by simulating the actions of a human user: clicking buttons, reading screen content, copying values between applications, and filling in forms. Unlike API-based automation, RPA works at the user interface layer and does not require the software being automated to offer an API. It is especially useful for legacy systems, desktop applications, and portals where no integration exists.
RPA automates repetitive computer tasks by mimicking how a human interacts with software, clicking, typing, and copying, without needing an API.
What RPA Actually Does
When you watch an RPA robot in action, it looks like someone using a computer in fast forward. The robot opens an application, reads values from one field, switches to another application, types those values in, clicks Save, and moves to the next record. It operates entirely on the visual layer of the software, the same layer a human would use, which means it works whether the target system is a 30-year-old mainframe terminal, a government web portal, or a modern desktop application.
This is what makes RPA uniquely powerful in organisations with legacy systems. If a finance team spends three hours every Monday copying purchase order numbers from a PDF into an ERP system that was built in 2001 and never received an integration layer, RPA can take over that task without any changes to the ERP.
How RPA Differs from API Automation
The distinction matters because it determines when to use each approach.
API automation connects systems at the data layer. A tool like n8n or Power Automate calls an API endpoint, receives structured JSON data back, and passes it to the next step. This works only if the target system exposes an API, but when it does, the automation is fast (thousands of records per minute), reliable, and unaffected by visual changes to the application’s interface.
RPA connects systems at the UI layer. It reads text from the screen, identifies buttons by their position or label, and types keystrokes. This is inherently slower (limited by screen rendering speed) and more fragile (a UI redesign can break a robot), but it works for any software that can run on a screen.
The decision rule is simple: if an API exists, use it. If no API exists and the task is repetitive enough to justify automation, use RPA.
Common RPA Tools
Three platforms dominate the market at different price points.
Power Automate Desktop is Microsoft’s RPA tool, included in Windows 11 and available with a premium licence for full cloud orchestration. It integrates tightly with the rest of the Power Platform, making it a natural choice for organisations already using Microsoft 365. For a comparison of how it relates to cloud-based automation, see n8n vs Power Automate.
UiPath is the market leader for enterprise RPA. It offers a full studio environment for building complex robots, an orchestrator for managing hundreds of robot instances, and a marketplace of pre-built automation components. Licensing is subscription-based and scales with the number of robots and features.
Automation Anywhere is another enterprise platform with a strong focus on cloud-native deployment and AI-assisted process discovery. It is positioned at a similar level to UiPath and is often found in large financial institutions and healthcare organisations.
For small and medium-sized businesses, Power Automate Desktop is usually the most cost-effective starting point because it requires no additional licences if you already pay for Microsoft 365.
Typical RPA Use Cases in Practice
The most common RPA implementations in mid-sized companies target three categories of work.
Data re-entry between systems is the largest category: copying records from a supplier portal to an internal system, transferring data from accounting software to a reporting tool, or moving information from email attachments into a database. These tasks are time-consuming, error-prone when done manually, and have zero business value as manual work.
Report generation and distribution involves opening a series of applications, extracting figures, assembling them into an Excel or PDF report, and emailing it to a distribution list. Finance and operations teams often spend two to four hours per week on reports that an RPA robot could generate in five minutes.
Legacy system interaction covers everything that modern integration tools cannot reach: green-screen terminals, proprietary desktop software, and web portals that block programmatic access. RPA is often the only practical option for these systems without a costly re-implementation.
When API Integration Is the Better Choice
If a system offers an API and you are using a tool like n8n or Power Automate’s cloud connectors, API integration is almost always preferable to RPA. An API call takes milliseconds and can process thousands of records in the time an RPA robot handles ten. API integrations do not break when the UI is redesigned. They are easier to test, monitor, and maintain.
RPA is a powerful bridge for gaps that API integration cannot reach. But it is a pragmatic workaround, not a strategic architecture. If a legacy system is central to your business and you rely on RPA to keep it connected, a longer-term plan to replace or properly integrate it will reduce your automation maintenance burden significantly.
Our tip: Before investing in RPA for a process, spend 30 minutes checking whether the target system has an API that you missed. Many older ERP and accounting systems added REST or SOAP APIs in recent updates, and a vendor’s integration catalogue is often out of date. A quick test API call can save weeks of RPA development.
Frequently asked questions
What is the difference between RPA and API automation?
API automation connects two systems at the data layer: one system sends a structured request to another's API, and receives a structured response. It is fast, reliable, and works regardless of whether anyone is watching a screen. RPA works at the UI layer, controlling a real (or virtual) screen exactly as a human would. If the screen layout changes, the robot may break. API automation is always preferable when an API exists, because it is more robust and often ten to a hundred times faster than RPA. RPA fills the gap for systems that have no API, such as legacy ERP software, government portals, or desktop applications from the 1990s.
What can RPA actually automate in a typical office environment?
Common RPA tasks include copying data from a PDF invoice into an accounting system that has no import function, transferring records from a legacy ERP to a new cloud platform one row at a time, filling in web forms on a supplier portal that has no API, generating monthly reports by opening Excel, running macros, and emailing the result, and logging into a government portal to download statements and save them to a shared drive. Any task where an employee opens the same application every day and performs the same sequence of clicks and keystrokes is a candidate for RPA.
When does RPA make more sense than building an API integration?
RPA makes sense when the target system has no API and the vendor cannot or will not provide one, when the process involves a legacy desktop application that cannot be updated, or when the volume of work is high enough to justify automation but not high enough to justify custom development. A practical threshold: if an employee spends more than two hours per week on the same repetitive task, RPA can typically pay back its implementation cost within three to six months. If the system does have an API, use it instead. API integrations are faster to run, easier to maintain, and far less sensitive to cosmetic changes in the user interface.