What is an application programming interface first approach?
An application programming interface first approach means preferring a supported integration wherever the target system offers one, and reserving screen automation for systems that offer none. The ordering is deliberate: a published interface carries a contract and a stated error response. Screen automation carries neither of those, so it belongs in the exception case rather than the default.
Also called: API first
Why the integration method determines the maintenance bill
The cost of choosing screen automation where an interface existed arrives two upgrades later, in a maintenance budget nobody forecast. Every release of the target application becomes a regression risk, and the team maintaining the automation has no notice of it. A supported interface moves that risk onto the vendor's own compatibility commitment. The decision is taken once per integration and then paid for continuously.
- A published interface has a contract that a screen layout does not.
- Interface changes are announced, where screen changes arrive without notice.
- Integration choices made per system accumulate into the maintenance bill.
- Reserving screen automation for genuine gaps keeps the fragile surface small.
How an application programming interface first approach works
- Each system in the workflow is assessed for a supported integration first.
- Available endpoints are checked against the actions the workflow actually needs.
- Authentication is arranged through the system's own service account mechanism.
- Where no endpoint covers an action, screen automation is scoped to that action alone.
- Each screen automation is registered against the gap that justified it.
- Registered gaps are revisited whenever the target system publishes new endpoints.
How an application programming interface first approach is evaluated
The test of this approach is how much of the workflow depends on a screen that can change. Measure the following per workflow and per system:
- proportion of actions served by a supported integration
- count of screen automations carrying a registered justification
- failure rate of screen steps against integration steps
- elapsed time to restore a workflow after a target application upgrade
- coverage of available endpoints against the actions needed
Limitations, risks and common failure modes
- An interface exists and nobody thinks to ask the owning team about it.
- Screen automation adopted for speed becomes permanent once it works.
- Published endpoints cover reading and omit the write action the workflow needs.
- A service account is refused, so a person's credential ends up inside the automation.