Legacy API vs Middleware vs RPA: How to Choose an Integration Pattern

Not a tool contest. An operating contract. API vs middleware vs RPA is the wrong question until the team can name the operation, timing, transaction, permissions, failure path, and support owner. Use a supported API for a defined record operation, middleware for shared mapping and coordination across systems, events for change triggered work, and controlled RPA only when a stable screen is the only practical interface. Choose the smallest pattern that passes every mandatory control and recovery gate.

Legacy integration projects go wrong when architecture starts with a product category. The team buys an integration platform, declares an API first policy, or automates a screen before it has written the business result. The missing decisions surface later as duplicates, stale data, hidden retries, broad credentials, manual reconciliation, and an owner who discovers the support burden after launch.

This guide turns the choice into an evidence based decision. It extends the legacy system integration guide, the secure API development guide, and the workflow orchestration guide. The Enterprise AI and Process Transformation hub connects the wider operating sequence.

API vs Middleware vs RPA Is a Pattern Decision

Start with one operation, not one system. “Connect the ERP” is not an operation. “Create an approved supplier record after identity, tax, and sanctions checks” is. The second statement exposes inputs, decisions, permissions, target changes, confirmation, exceptions, and evidence. Those details decide the pattern.

The practical choice is broader than three labels. Events deserve a separate lane because asynchronous change notification behaves differently from a request and response API. The four useful comparison lanes are:

• Supported API: a documented interface performs the required operation directly.
• Middleware: a coordination layer maps, routes, transforms, monitors, or holds workflow state across systems.
• Events: a producer publishes a change and one or more consumers react without blocking the producer.
• Controlled RPA: a bot uses the same screen path as a person because no suitable interface exists.

These patterns can coexist. They should not overlap by accident. Every layer needs a clear reason to exist and an explicit owner for state, retry, evidence, and recovery.

Public Evidence Changes the Pattern Decision

NIST SP 800-228 treats APIs as integral to enterprise integration and separates protection before runtime from protection during runtime. OpenAPI 3.1 provides a machine readable description for HTTP interfaces, but a valid description does not prove business correctness, reliable recovery, or safe permissions. The OWASP API Security Top 10: 2023 identifies ten recurring API risk categories. Those sources make interface contract, access, validation, inventory, and runtime behavior part of the architecture choice.

Microsoft architecture guidance describes queues as load leveling and temporal decoupling mechanisms. It also calls out duplicate delivery, ordering, idempotency, dead letter handling, and reconciliation. Its event architecture guidance notes that event streams can arrive more than once or out of order. That makes an event pattern useful, but not free of state and transaction obligations.

Microsoft desktop automation documentation lists three selector approaches and explains that resolution, application updates, operating system changes, window state, and permissions can affect screen automation. That makes RPA a governed interface with change exposure, not a shortcut around integration design.

Original GS Research: The Integration Pattern Fit Index

GS Consulting built the Integration Pattern Fit Index to compare supported API, middleware, events, and controlled RPA across four representative legacy integration scenarios. The model rates ten factors from one through five, then applies scenario weights totaling 100. Each result is the weighted rating divided by five, producing a zero through 100 fit score.

The ten factors are supported operation fit, cross system coordination, asynchronous scale, screen only reach, transaction control, security boundary, recovery and reconciliation, change resilience, observability, and delivery speed. Ratings, scenario weights, assumptions, formulas, public sources, sensitivity weights, and figure data are preserved in the research workbook.

The supported API scores 90 for a defined record operation. Middleware scores 87 when many systems need shared mapping and coordination. Events score 88 for change triggered background work. Controlled RPA scores 72 when a stable screen is the only reachable interface. These are scenario results, not permanent rankings. A pattern can score well overall and still fail a mandatory gate.

The sensitivity case shifts weight toward recovery and reconciliation. Every preferred pattern remains unchanged, and no score moves by more than four points. That result shows limited stability under one alternate assumption. It is not market validation.

This is a GS Consulting derived planning model based on cited public sources and documented assumptions. It is not a product selection, audit, legal, security, NIST, OWASP, Microsoft, or regulatory determination.

Use Each Integration Pattern for the Work It Fits

Supported API for a Defined Operation

An API is the first choice when the system exposes the exact record or action the workflow needs. Prove the specific product, version, endpoint, fields, permissions, limits, error responses, transaction behavior, and vendor support statement. A generic API page is not enough.

APIs are strongest when the caller needs an immediate answer, the contract is documented, the operation can be made safely repeatable, and the target can confirm the business result. They are weaker when the required operation is missing, only an unsupported internal endpoint exists, or the business transaction crosses several systems without a coordination owner.

Middleware for Shared Mapping and Coordination

Middleware earns its place when several consumers need the same mappings, routing, policies, connectors, monitoring, or workflow state. It can prevent every application team from rebuilding the same transformation and retry logic.

The danger is invisible ownership. A map becomes a business rule. A retry becomes a transaction decision. A route becomes an access path. Document who owns those choices, where source truth remains, how changes are tested, and how operators can reconcile incomplete work. Middleware should reduce duplicated coordination, not hide it.

Events for Change Triggered Work

Events fit a producer that needs to announce a fact without waiting for every downstream action. They support background processing, many consumers, independent scaling, and loose time coupling. They also introduce schema evolution, ordering, duplicate delivery, replay, retention, and consumer ownership.

Treat an event as a statement that something happened, not a command that silently transfers accountability. Name the producer, event schema, business key, timestamp, version, consumers, retention, replay rule, duplicate rule, dead letter path, and reconciliation process.

Controlled RPA for the Screen Only Gap

RPA can be the honest answer when a legacy product has no supported interface, the screen path is stable, the volume is bounded, and the action is observable and reversible. It can also provide a bridge while a better interface is delivered.

The bot must be treated as an integration component. Narrow its identity, restrict allowed actions, pin the environment, detect screen and selector changes, capture target confirmation, stop on ambiguity, and assign a human recovery path. A bot that clicks through unexpected state is not resilient automation.

Score Eight Operating Checks Before Choosing

• Supported operation: can the interface perform the exact read, decision, write, and confirmation the workflow requires?
• Coordination: how many systems, mappings, routes, approvals, and shared state transitions are involved?
• Timing: must the caller receive an immediate answer, or can work complete asynchronously?
• Transaction: what must be atomic, ordered, repeatable, compensable, reviewed, or reconciled?
• Security: which identities, data, operations, secrets, and environments cross the boundary?
• Recovery: how will operators detect, pause, repair, replay, reverse, and confirm failed work?
• Change: what happens when schemas, endpoints, screens, selectors, versions, limits, or business rules move?
• Operations: who monitors, supports, tests, releases, documents, and eventually replaces the integration?

Set rejection gates before scoring. An unsupported write, prohibited data path, unrecoverable partial effect, or missing support owner can eliminate a pattern even when its weighted fit is highest.

Follow a Six Stage Decision Path

1. Name the operation. Record the trigger, source fact, decision, target change, confirmation, owner, and prohibited behavior.
2. Prove supported interfaces. Test the exact product, version, operation, permission, limit, and response behavior in a representative environment.
3. Set transaction needs. Decide what must be immediate, ordered, atomic, safely repeatable, compensable, approved, or reviewed.
4. Score the smallest pattern. Compare all viable patterns against the same scenario and reject any that fail a mandatory gate.
5. Test failure and change. Exercise denial, timeout, duplicate, stale data, partial effect, recovery, and interface change.
6. Combine only with clear ownership. Assign state, retry, decision, evidence, and support to one named layer for each responsibility.

Combine Patterns at Explicit Boundaries

A realistic legacy flow might use an API to read the system of record, middleware to map fields and coordinate approvals, an event to notify downstream consumers, and RPA to update one isolated screen only system. That can be sound. It can also create four places that believe they own the transaction.

Write a boundary table for every handoff. Name the input, output, schema, business key, owner, timeout, retry rule, duplicate rule, evidence, and recovery action. Mark which system holds authoritative state. If two layers can retry the same write, decide which one is allowed to do so and disable the other. If two systems can declare completion, choose the source that confirms the actual business result.

Prefer fewer stateful layers. Mapping can be shared. Monitoring can be centralized. Business truth should not be copied into a coordination product without a clear reason and reconciliation rule.

Design Transactions Before Retries

A retry policy is not a transaction model. Before adding retries, classify the operation:

• Read: can the result become stale, and how will the workflow detect it?
• Create: what key prevents a duplicate record when the response is lost?
• Update: what version or condition prevents overwriting a newer change?
• Multi system action: what is the safe sequence, and which steps can be compensated?
• Human decision: what happens when approval expires, conflicts, or arrives after the target changed?

Queues and events commonly use at least once delivery. Consumers therefore need a durable business key, duplicate detection, and a reconciliation path. If an operation cannot be repeated safely, the workflow needs target confirmation before it decides what to do next. Never infer success only from the absence of an error.

Treat the Integration as a Security Boundary

List every identity, secret, field, operation, environment, log, and administrator that crosses the connection. Separate read, write, approve, deploy, pause, replay, and recover authority where the risk warrants it. Validate the object and action, not only the session. Keep an inventory of versions and endpoints. Record where sensitive data moves and how long it remains.

NIST SP 800-228 and the OWASP API Security Top 10 support disciplined API design and runtime protection, but they do not choose the pattern for a specific workflow. Use them to shape evidence and tests. Legal, privacy, contractual, and regulatory obligations remain specific to the organization and use case.

For a practical control sequence, pair this decision with the secure API development guide and the legacy database extraction guide.

RPA Needs an Exit Condition

Screen automation becomes permanent when the bridge has no owner, no replacement trigger, and no cost record. Define its exit condition on day one. Useful triggers include a supported API becoming available, selector repair exceeding a set threshold, volume exceeding safe capacity, an audit gap, a prohibited permission, or a material change in the target application.

Measure selector failures, session failures, ambiguous screens, target mismatches, manual corrections, repair time, and application changes. Test the bot after product, operating system, browser, resolution, and permission changes that affect its path. Keep a manual procedure that operators can actually execute.

Make the Pilot Prove the Operating Contract

A useful pilot is one bounded workflow in a representative environment. It proves the interface and the negative cases, not only the happy path. Set acceptance criteria before the build starts:

• All required products, versions, operations, fields, permissions, limits, and support assumptions are verified.
• Normal completion and target confirmation meet the agreed accuracy and timing thresholds.
• Denied access, timeout, duplicate, stale input, malformed input, partial effect, wrong target, and dependency failure are detected.
• Operators can pause, reconcile, repair, replay where safe, and preserve an evidence record.
• Source load, queue depth, latency, manual correction, and support effort remain within declared limits.
• A named team accepts monitoring, release, recovery, vendor change, documentation, and exit duties.

The GS private AI cyber analysis case study shows the same discipline in practice: the work focused on controlled interfaces, human review, and delivery into approved systems rather than an isolated model demo.

Test the Failures That Survive a Demo

Six failures deserve an explicit test. An API label may not prove the required operation. Middleware may hide mappings and state. Events may be treated as ordered despite duplicate or delayed delivery. RPA may become the default for every missing interface. A workflow may report success without confirmed target state. Two layers may retry the same transaction.

Do not bury these cases in a general test plan. Give each one an expected detection signal, owner, operator action, evidence record, and recovery time. If the response is “inspect logs,” name the log, field, business key, query, retention, and person who acts.

Keep a Minimum Integration Pattern Evidence Packet

1. Operation contract: trigger, input, decision, action, prohibited behavior, and target result.
2. Interface proof: product, version, endpoint or screen, permissions, limits, errors, and vendor support.
3. Pattern scorecard: scenario weights, ratings, rejection options, and combination boundaries.
4. Transaction model: ordering, duplicate rules, atomicity, compensation, review, and confirmation.
5. Security boundary: data path, identities, secrets, allowed operations, and audit events.
6. Adverse case tests: denial, timeout, stale data, duplicate, partial effect, and wrong target.
7. Recovery record: pause, retry, repair, replay, reconciliation, and owner decisions.
8. Operating handoff: monitoring, support, change tests, vendor duties, runbook, and exit.

A 90 Day Integration Pattern Plan

Days 1 Through 15: Frame the Operation

Select one high value workflow. Write its result, exclusions, business key, source fact, decisions, target change, timing, transaction, security, evidence, recovery, and owner. Inventory actual products and versions.

Days 16 Through 35: Prove Interfaces and Compare Patterns

Test supported APIs, middleware connectors, event capabilities, and the screen path where relevant. Score viable patterns against one scenario. Record mandatory gates and rejected options. Design the transaction and security boundary before implementation.

Days 36 Through 70: Build a Bounded Pilot

Implement the smallest pattern. Add target confirmation, observability, duplicate handling, failure signals, pause controls, evidence capture, and recovery. Exercise every adverse case in the acceptance plan.

Days 71 Through 90: Decide and Hand Off

Review measured results, unresolved dependencies, support effort, change exposure, residual risk, and total operating cost. Choose expand, revise, hold, or stop. Complete the evidence packet and obtain operating owner acceptance before production.

The operating standard: no legacy integration pattern enters production until the exact operation, interface, transaction, security boundary, failure response, reconciliation path, and support owner are proven in one bounded workflow.

Primary Sources and Method Notes

• NIST SP 800-228, Guidelines for API Protection for Cloud Native Systems
• OpenAPI Specification Version 3.1.0
• OWASP API Security Top 10: 2023
• Microsoft Azure Architecture Center, Asynchronous Messaging Options
• Microsoft Azure Architecture Center, Event Driven Architecture Style
• Microsoft Azure Architecture Center, Transactional Outbox Pattern
• Microsoft Power Automate, Automate Using UI Elements
• Microsoft Power Automate, Troubleshoot Unattended Desktop Flow Execution Failures
• NIST SP 800-53 Revision 5, Security and Privacy Controls
• Carnegie Mellon Software Engineering Institute, Architecture Tradeoff Analysis Method

The research package records source access dates, relevant findings, limitations, model assumptions, formulas, sensitivity results, figure data, and the GS case study used as implementation context. Scores support planning and structured review. They do not determine compliance, product fitness, or legal obligations.

Frequently Asked Questions

How do you choose between API, middleware, and RPA?

Define the exact operation, prove the interfaces, set timing and transaction needs, test security and recovery, then score the smallest pattern that meets every mandatory gate. Use an API for a supported record operation, middleware for shared mapping and coordination, events for change triggered work, and controlled RPA only when a stable screen is the only practical interface.

Is an API always better than RPA for legacy integration?

A supported API is usually more stable and testable than screen automation, but it is not automatically complete. The API must expose the required operation, version, permissions, limits, transaction behavior, errors, and support commitment. RPA can be reasonable when no supported interface exists and the screen path is stable, low volume, observable, reversible, and owned.

When should middleware be used for legacy integration?

Use middleware when several systems need shared mapping, routing, policy, state, retries, monitoring, or reusable connectors. Keep business truth in the systems of record and make ownership explicit so the middleware does not become an undocumented black box.

When are events the right integration pattern?

Events fit change triggered work where the producer should not wait for every consumer. They require explicit schemas, ordering expectations, duplicate handling, replay rules, dead letter handling, reconciliation, and ownership. Event delivery does not remove transaction design.

Can API, middleware, events, and RPA be combined?

Yes, but each layer must own a distinct responsibility. One component should own transaction state, one should decide retry, and one source should confirm the business result. A combined design is unsafe when two layers can advance the same transaction independently.

What should a legacy integration pilot prove?

A pilot should prove normal completion, denied access, timeout, duplicate input, stale data, partial effect, target mismatch, interface change, recovery, reconciliation, evidence capture, and named support ownership. It should also measure source load, latency, correction effort, and operating effort.