Autonomy Docs

API and network

Test an API directly with outcome steps, and read the network requests behind a web run.

Journeys often look fine in the browser while the system behind them fails. Autonomy covers both sides: API test cases call your endpoints directly, and web runs keep every request the page made.

Test an API

Add an API target to an environment: the base URL of your API, such as https://api.staging.example.com. Then create a test case with the API platform. Its runs send HTTP requests directly, with no browser or device.

Write the steps as outcomes, the same way as on web:

  • A new order can be created for the test customer.
  • The new order is listed with the status paid.
  • An order request without a token is refused.

The agent works out the requests, sends them, and checks the responses. Keep tokens and keys in environment values marked secret and refer to them as {{env.NAME}}; they're sent by reference and never shown.

To draft API steps from a spec, choose Describe what to test and attach your OpenAPI .yaml or .json file. Its text is used as context for the draft.

An API run shows Requests in its evidence: each request the agent sent, with its response.

Network evidence in web runs

A web run keeps every request the page, its frames and its workers made. Open the run's Network tab:

  • Each request with its method, status, type, size and time, and a waterfall of when it ran, divided by step.
  • Request and response headers, cookies included, and bodies: the first 256 KB of each.
  • Filters to find a request quickly.

The Console tab has every console message at every level, uncaught errors and unhandled promise rejections, and the browser's own messages. Values are shown as the page saw them; only values you saved as secrets are masked.

Problems become issues

Console errors and failed page, fetch and XHR requests seen during a run are flagged by an automatic check and listed under the run's Issues found, even when every step passed. They never change the result. See Issues.

Review pattern

Start with the step that failed and its outcome line. If the screen is ambiguous, open the Network tab at the time of that step: a failed request or a slow third-party call often explains what the user saw.

Didn’t find it?

On this page