API integration or screen automation: which dependency can you support?

Choose an integration route by the dependency you can maintain. A supported API and a screen-driven automation can both be useful, but they fail and require support in different ways.

Compare the interface being used

An API provides a defined programmatic interface for supported operations. Screen automation interacts with the user interface, often through desktop or browser controls. Neither label alone establishes reliability, security or permission to perform the intended action.

Begin with the business operation and check what the supplier actually supports. A product may offer an API for reading records but not for the write you need. A desktop application may require a licensed session, a particular environment or human participation.

Use a dependency comparison

Decision area	API route	Screen automation route
Interface change	Review versions and changed request or response behaviour.	Review layout, controls, selectors and session behaviour.
Access	Application or user permissions for the operation.	Authorised session and permitted UI actions.
Failure evidence	Response codes, request identifiers and destination reconciliation.	Observed screen state, step result and business-record reconciliation.
Operation	Rate limits, service availability and entitlement.	Machine/session availability and supported execution mode.
Maintenance	Owner for interface and credential changes.	Owner for UI, environment and selector changes.

Test the business result, not just the last step

An HTTP success response may still require checking the returned record. A clicked button may not prove that the intended change was saved. In either route, identify the result at the authoritative destination and retain a suitable case reference.

Test a timeout or interrupted session after the action may have occurred. The recovery procedure must determine whether to resume, reconcile or stop. Blind repetition is especially risky when the action creates a new record or sends a message.

Ask who will maintain the route

A desktop sequence can depend on a specific application version, display state or signed-in user. A supported API can depend on a subscription, permission grant or version lifecycle. Make those assumptions visible in the proposal rather than treating them as implementation trivia.

Ask for a handover that identifies configuration, access ownership, failure visibility and change tests. Microsoft’s desktop automation documentation describes UI elements and selectors; the practical implication is that the selected controls and environment need deliberate maintenance.

Choose a reversible first boundary

• Use the supported interface for the exact operation where it meets the requirement.
• Confirm entitlement and authorised access before building.
• Start with a limited read or reviewable output where practical.
• Test duplicate and interrupted cases before consequential writes.
• Include ongoing maintenance in the comparison.

The right choice may be to defer a connection until a supported interface or clearer operating model exists. That is a specific integration decision, not a reason to abandon the wider process improvement.