RPA vs API integration

What it does

Settles whether a given automation should go through the target system's interface or its API, and — more usefully — decides whether RPA is the destination or a waypoint. Most RPA that goes wrong went wrong because nobody wrote down which of those two it was meant to be.

Key facts

Microsoft's guidance ranks connectors and custom connectors above browser and desktop automation specifically on resilience to system change. Everything else in this comparison follows from that one property.
Unattended RPA runs on a machine or machine group with a Process licence allocated, or on hosted machines with Hosted Process. One bot runs one desktop flow at a time, so concurrency is a purchasing decision.
Attended RPA is included with a Power Automate Premium user licence as a single attended bot on that user's registered machine. It's designed for a person sitting at the desk, not for scheduled overnight work.
Hosted machine groups give you virtual machines that scale for unattended work without an Azure subscription of your own, which removes the infrastructure argument but not the licence cost.
Attended and unattended automation shouldn't share a machine or machine group: one needs an active session, the other needs the session signed out or disconnected.
API-based automation bills as actions against your request allocation. RPA bills as actions plus bot capacity plus the machine estate underneath it. The second cost line is the one that gets left out of business cases.

When to use / skip

RPA is the right permanent answer in a narrow set of cases: the vendor genuinely has no API, the system is going out of service within a defined window and nobody will fund integration work on it, or the process is low-volume, human-paced and attended anyway. In those cases build it properly, licence it properly, and stop apologising for it.

Everywhere else RPA is a stopgap, and the discipline is to name it as one. The pattern that works is: build the RPA, deliver the benefit now, and attach exit criteria to it in the same document that carries the ROI number. The pattern that fails is building the RPA, banking the saving, and discovering four years later that thirty bots are load-bearing, undocumented and maintained by one contractor. That outcome is what gives RPA its reputation, and it's a governance failure rather than a technology one.

Configuration decisions

Is this permanent RPA or bridging RPA? Decide it explicitly and record the answer, because everything downstream — funding, ownership, documentation standard — differs.
If bridging, what are the exit criteria and who owns them? "When the API is delivered" is not a criterion; "when the vendor ships v4 in the FY27 roadmap, or by 31 March, whichever is first" is.
What's the fallback when the bot fails mid-process — retry, requeue, or route to a person? Work queues exist for exactly this and are underused.
Attended, unattended, or hosted, and how many parallel runs the process needs at peak rather than on average.
Who holds the credentials the bot uses, and what happens to the automation when that account's password policy changes.

Gotchas

Total cost of ownership for RPA is dominated by change, not by build. Every upstream release is a potential regression, and someone has to test the bots against it. Budget a standing maintenance allocation or expect emergency work.
Bots inherit the permissions of the account they run as. It's very easy to end up with a service account holding far more access than any human in the process, and security will find it eventually.
RPA hides process debt. Automating a broken fifteen-step manual process makes it fast and permanent. Do the process work first or you've built a monument to it.
Business cases usually count the FTE saving and not the bot licences, the VM estate, the maintenance headcount or the failure-handling effort. Net benefit can be a third of the headline.
Nobody notices when a bot stops. The process just gets slow, work piles up somewhere, and it surfaces as a business complaint two weeks later.

Consultant notes

Write the exit criteria into the business case itself, not into a technical design document nobody reopens. Finance reads the business case; that's where the sunset clause survives.
Give every automation a review date and an owner at go-live. A bot with no named owner has a maintenance budget of zero by default.
When you propose RPA, propose the API replacement alongside it with a cost. Clients often approve both once they can see the maintenance curve.
Push for process mining or at least a proper as-is walkthrough before automating anything with more than about ten steps. The step that everyone forgot to mention is the one that breaks the bot in week three.
Be candid that RPA is the tactical option. Consultants who oversell it as strategy are the reason the next consultant inherits an estate nobody can decommission.

Pull this out whenever a business case for bots arrives without a sunset date attached