Automating a TMS without an API: user-interface interaction, controls and limits

What “without an API” actually means

The operator uses the available interface to locate a record, populate fields or trigger an action. It does not bypass authentication or assume that all screens are identical. Access, actions and controls are defined for the specific environment after qualification and validation.

This approach mainly addresses situations where a business function exists in the interface but is not exposed through a usable connector. It must be compared with a conventional integration according to volume, stability and risk.

A reliable action has six stages

1. 01
   Observe

   Confirm the expected application, screen and current state.

2. 02
   Locate

   Find the correct record using verified identifiers.

3. 03
   Populate

   Apply values from the validated context.

4. 04
   Review

   Compare the visible fields with the intended action before approval.

5. 05
   Execute

   Trigger only the authorised action.

6. 06
   Verify

   Check the resulting message, status or value and retain an audit trail.

Situations that must stop the workflow

• an expected screen, field or label cannot be found;
• several records could match the same reference;
• the displayed value differs from the prepared value;
• the session has expired or access rights are insufficient;
• an error message is not recognised;
• the action would have an impact beyond the authorised scope.

API or user interface: decide case by case

A stable API generally provides a more direct contract that is easier to test. The user interface provides coverage when that contract does not exist or remains incomplete. Both approaches can coexist within the same workflow.

Vigilo’s scoping process documents the selected method, control points, limits and recovery strategy. It is designed to adapt to heterogeneous TMS environments and workflows, but feasibility and reliability are qualified and validated for each target environment rather than claimed as universal compatibility.

Decision matrix: API, file exchange or user interface

“Without an API” describes a possible constraint, not an architecture to impose. A single workflow may read data through an API, receive a file and use the user interface for an action that is not exposed elsewhere. The route should therefore be selected separately for every required read, write and check.

Qualification conditions before the first write

Qualification starts with a specific action—such as creating an order, changing a time slot or attaching a document—not with a general promise to “automate the TMS”. For each action, the team describes the permitted cases, acceptable starting states and the evidence that will establish the outcome.

• the actual environment, version, screen or function in use;
• the identifiers that unambiguously designate the record and its version;
• the account, roles and minimum required access rights, with a named owner;
• the session lifecycle, expiry, sign-out behaviour and multi-factor authentication (MFA) policy;
• observed volumes, frequencies, response times and asynchronous processing;
• the expected state before the action, verifiable outcome and normal time to visibility;
• prohibited cases, unknown messages and thresholds that require a stop or human approval;
• a tested recovery strategy, incident owner and the evidence to retain.

Sessions, MFA and interface changes: three states to design for

An expired session is not an error to hide. The workflow must recognise the sign-in page or missing session, stop before entering data and request reauthentication in line with company policy. If an MFA challenge requires a person to intervene, that step remains human; the automation must neither obtain a code through an unauthorised channel nor attempt to bypass the control.

An interface change is handled in the same way: a missing field, new dialog, moved label or altered sequence invalidates the expected anchors. The affected workflow is suspended, the new version is reviewed and the controls are run again before service resumes.

1. 01
   Recognise

   Distinguish the expected business screen from sign-in, an MFA challenge, an error or an unknown version.

2. 02
   Do not improvise

   Do not click a lookalike element, guess a new sequence or broaden access rights to keep going.

3. 03
   Hand over the context

   Give the team the intended action, the last confirmed state and the exact interruption point.

4. 04
   Revalidate

   Test the authentication flow or changed interface and its outcome evidence before writes are authorised again.

Recover without repeating an uncertain action

After a network interruption, session expiry or frozen screen, it may be unclear whether the action was recorded. An immediate retry could create a second order, apply the same change twice or attach a duplicate document. Recovery therefore begins with a fresh observation, never by repeating the last click.

1. 01
   Freeze the attempt

   Retain the reference, prepared values, time, last confirmed screen and observed messages.

2. 02
   Read an authoritative source again

   Find the record, its identifier, version and state through the most reliable authorised route.

3. 03
   Classify the outcome

   Distinguish confirmed success, confirmed absence and an indeterminate state; a missing confirmation screen is not enough.

4. 04
   Choose the recovery

   Retry only when absence is established and the validated strategy rules out duplicates and contradictions.

5. 05
   Escalate when necessary

   When several states remain plausible, hand the record and available evidence to a person and wait for a decision.

Three resources, three different decisions

This guide answers a technical question: how to qualify and control an interaction when an API does not cover the action. The commercial page about TMS automation without an API presents Axonovia’s offering and approach; it does not replace this qualification method.

The guide “Automating operations without changing your TMS: how to decide” covers a broader architecture and investment decision: use a native feature, add a complementary layer or consider a migration. This guide comes next when a specific integration route needs to be assessed. It is not a reason to keep a TMS, nor does it dismiss the TMS vendor’s native capabilities.