A supported API is usually the best automation interface. It is direct, testable, and easier to operate than a GUI. OpenAdapt is not an argument against APIs. It handles the last mile when the required operation exists only behind a browser, desktop application, RDP session, or Citrix window.
The companion article traces the maintenance and failure costs in more detail. Read the comparison article.
Every claim below names its public source. If a vendor doesn't publish a figure, we don't invent one.
OpenAdapt
A compiled workflow re-resolves targets from retained evidence, produces a governed repair proposal, or halts when the visible interface changes beyond its contract.
a supported API
An API bypasses interface layout entirely. Its callers depend on the service's published request, response, and authentication contract instead of screen geometry.
Source: HTTP semantics · OpenAdapt method
OpenAdapt
A healthy compiled run makes no model call, but GUI execution still needs a browser, desktop, or remote session.
a supported API
A direct HTTP API exchanges request and response messages without GUI actuation. Provider charges and rate limits are service-specific.
Source: HTTP messages · OpenAdapt method
OpenAdapt
OpenAdapt separates actuation from verification. A read-only API, SQL query, file check, or second interface can prove the effect after the GUI action.
a supported API
A response status describes how the server handled the request. For consequential work, the caller can add a separate read-back or postcondition check instead of treating request acceptance as the complete business result.
Source: HTTP status code semantics · OpenAdapt effect-verifier kit
OpenAdapt
The workflow refuses before actuation when identity, target, or policy checks fail. If an action may have been dispatched but its effect cannot be proved, it returns RECONCILIATION_REQUIRED without a blind retry.
a supported API
The client owns error handling, idempotency, retries, and reconciliation. HTTP defines conditional request and method semantics, but the application must use them correctly.
Source: HTTP conditional requests · OpenAdapt execution outcomes
OpenAdapt
The GUI runtime and retained evidence can stay inside a customer-controlled boundary.
a supported API
The client sends request messages to the API server. The service's deployment contract governs the data after it crosses that network boundary.
Source: HTTP messages · OpenAdapt trust center
OpenAdapt
OpenAdapt handles operations that exist only through browser, native desktop, or customer-qualified remote-window interfaces.
a supported API
An API is the best fit when the service owner exposes the complete operation through a supported machine interface. HTTP defines the exchange, while the service defines the available business operations.
Source: OpenAdapt comparison overview · HTTP semantics
Source: HTTP semantics
Source: HTTP message semantics
Recording demonstrations, visual targeting, virtual desktop awareness, and selector repair are common. OpenAdapt binds independent effect verification and explicit outcomes to the workflow contract.
A run is judged by an out-of-band check of the system of record, such as a read-only API call, a SQL query, or re-reading the persisted record, not by the acting session declaring itself successful.
Every consequential run ends with a typed outcome and a preserved run report. VERIFIED requires independent proof. A refusal before actuation and uncertain delivery after possible actuation remain distinct, so an unconfirmed write cannot appear as success.
A compiled workflow replays deterministically with zero model calls on healthy runs. Model spend is reserved for compilation and reviewable repair.
For managed Citrix, RDP, and VDI estates, OpenAdapt can drive the local client window from outside the session, so nothing is installed inside the remote environment. The lane is qualified today against a deterministic stand-in and a real FreeRDP round trip; a real ICA/HDX environment is qualified per customer before consequential use.
Recordings, screenshots, and compiled bundles can stay inside your boundary. Local, self-hosted, and customer-controlled deployments are first-class, not an enterprise afterthought.
The compiler and governed runtime are MIT-licensed and inspectable. You can audit exactly what runs beside your systems of record.
Each execution surface ships with bounded, published acceptance evidence, counted effects, refusals, and halts, instead of an unbounded compatibility claim.
Per-surface acceptance results are published in the qualification evidence.
No. Use the supported API for the complete operation. OpenAdapt fits the steps the API does not expose, or that your licensing tier, vendor agreement, or IT approval will not let you reach. Verification does not depend on that API either: a read-only API, a database query, a file check, or reacquiring the record through the interface can all prove the effect.
Source: HTTP semantics · OpenAdapt comparison guide
Choose the API when it exposes the complete operation you need, its use is permitted, and you can verify the resulting record through the same or a separate read-only interface.
Choose OpenAdapt for the exact steps the API does not expose, including legacy, desktop, remote, and vendor-controlled interfaces. Keep API calls for the parts they can do, including independent verification after GUI actuation.
Use APIs for data movement, orchestration, and verification. Limit OpenAdapt actuation to the UI-bound transaction that the API does not expose.
Bring one repeated, consequential workflow and measure authoring time, run time, intervention rate, and incorrect-success rate against your current approach. Or watch the governed-execution demo first. It shows result checks and safe stops against the retained event evidence.