RPA is a workaround for a missing API, and buying it otherwise is a category error

Two facts about the workflow settle the category, and neither of them requires a vendor. The first is whether an API exists on the systems involved. Robotic process automation exists for the case where one does not, or where getting access would take longer than building a bot against the interface a person already uses ^[3]. Business process automation works the other way, executing a workflow across systems through APIs, webhooks and defined process states rather than mimicking a screen at all ^[7]. A workflow with API access on both sides therefore has no RPA justification left in it ^[1]. The second fact is whether the input arrives structured enough to act on directly. RPA and BPA both assume it does ^[13]. A cognitive layer, meaning OCR and document understanding, NLP for unstructured text, and classification models, is what covers the cases where it does not ^[11].

The part of the dev.to argument that changes the purchase math is the claim that RPA's brittleness is structural rather than an implementation defect: visual interfaces change for reasons that have nothing to do with the automation depending on them, and the resulting failure is usually silent until someone notices the process stopped completing ^[4][5]. If that is right, then bot upkeep is a standing line item and not a ramp cost. A team comparing an RPA quote against the cost of getting API access on build price alone is comparing on the wrong axis, because only one of the two options keeps billing after it works.

The layering claim is the one most likely to be lost in a shortlist. The writeup treats RPA and BPA as different depths of the same stack rather than competitors, with a BPA workflow legitimately calling a bot for the single sub-task where no API exists while orchestrating everything else through proper integration ^[9]. That is an architecture decision, not a procurement decision, and it has two named failure modes when the categories are treated as interchangeable: forcing brittle UI automation onto a process that had API access the whole time, or asking one bot to hold branching, multi-system logic it was never built for ^[10]. A CRM trigger that waits for a response, branches on it, calls a second system and routes to a human queue when a condition fails is the shape of work that belongs at the orchestration layer ^[8].

Intelligent automation has a narrower honest test than the marketing implies. It earns its price when unstructured input is a real, recurring bottleneck, such as invoice PDFs whose layout varies by vendor, inbound email that has to be classified before routing, or scanned forms with handwritten fields ^[12][14]. Bought as a default upgrade to a structured, API-reachable process, it is a cognitive layer nobody uses ^[16]. This is one practitioner's map, published on dev.to and not a survey, and its examples are the familiar ones. What holds up independent of the taxonomy is the ordering: both diagnostic questions are answerable from your own system inventory, at zero cost, before anyone schedules a demo.