“No API” is usually more specific than it sounds
Some applications expose read access but not the write that completes a workflow. Others expose core records but omit an approval step, a specialized module, or a customer-specific extension. The endpoint may exist but be unavailable in the deployed edition, inaccessible through the organization’s network, or unsuitable for the identity and control model.
Document the actual gap before choosing a solution. Name the operation, the data it requires, the side effect it produces, and why available integration paths do not cover it. This prevents an interface project from duplicating a supported capability and gives security and operations teams a concrete action to review.
Turn a screen path into an action contract
An interface-backed tool should not expose “use this application” as an open instruction. It should expose a business operation with a schema. Required and optional fields are explicit. Preconditions describe the record state in which the operation is valid. Policy determines which identities may request it and when approval is required.
The interface path becomes an implementation detail behind that boundary. The calling agent should not need to know where controls are placed, which sequence of screens is involved, or how a confirmation is phrased. It should receive a structured result that distinguishes completion, rejection, recoverable failure, and uncertain state.
Controls matter more when the interface is the integration surface
- Use least-privilege application identities and separate read operations from consequential writes.
- Validate values and record state before opening a write path.
- Require an approval for actions that cross business-defined thresholds or affect sensitive fields.
- Use idempotency or duplicate detection where repeated requests could create duplicate business effects.
- Stop on unrecognized screens, unexpected warnings, or changed field semantics rather than improvising.
- Record the request, policy decision, execution outcome, and returned evidence at an appropriate level for the workflow.
Verify the record, not the motion
A submission can time out after the application commits a change. A success banner can appear even when a downstream validation fails. A record identifier can exist while important fields are missing. For that reason, the verification design belongs in the workflow contract, not as an afterthought.
Useful evidence depends on the action. It may include reading back changed fields, retrieving the assigned identifier, observing the expected status, or comparing an authoritative export. When no source-system fact can distinguish success from uncertainty, the workflow needs a human reconciliation path.
Know when not to use an interface-backed tool
Prefer a complete supported API when one is available. Keep open-ended, low-frequency exploration with a person or an explicitly supervised computer-use flow. Do not automate a process whose owner cannot define valid states or whose exceptions dominate the normal path.
The right outcome of an assessment can be “not suitable.” Authentication restrictions, virtual-environment controls, inaccessible evidence, unstable interfaces, or unacceptable operational risk may outweigh the value of removing the handoff.
Frequently asked questions
Why not let a general computer-use agent navigate each time?
That flexibility can suit exploration and variable tasks. A repeated business operation benefits from a stable schema, explicit policy, known failures, and reusable tests rather than rediscovery on every run.
Can a workflow combine an API and interface steps?
Yes in principle. A workflow may use supported APIs for available operations and an interface-backed adapter only for the missing step. The final design must still define one coherent authorization and evidence model.
Does “without an API” mean no integration work?
No. The work shifts to mapping, governing, testing, operating, and maintaining the interface-backed action. Avoiding an application replacement does not eliminate engineering or change management.
How is suitability determined?
By examining the exact workflow, application version and delivery environment, authentication, variability, controls, failure modes, evidence, and operational ownership.
Document the API gap.
Describe the missing operation and the interface path that still performs it. The assessment will focus on feasibility, controls, and proof of completion.