API scenarios
Test REST and HTTP services with API steps inside your web and mobile tests.
Add an API step when a test needs to call a service directly instead of going through the screen. You add it from the test builder like any other step. It behaves the same in a web test and in a mobile test, with the same checks on the response and the same timing metrics: only the surrounding test changes.
API actions
HTTP API actions are available inside existing tests:
- Inside a web test: add HTTP requests alongside browser steps. Action identifier:
ETH_HTTP_API. - Inside a mobile test: add HTTP requests alongside smartphone steps. Action identifier:
DATA_API_HTTP.
Both share the same request configuration and response assertion model, with a few channel-specific differences in routing.
In a Web (New experience) test, this is the API Call step: same request, plus response conditions written in the step's Checks tab and a response viewer in the builder and in the results. Classic tests, the CLI, and the MCP still refer to it by its identifier, ETH_HTTP_API.
Request configuration
- HTTP methods:
GET,POST,PUT,PATCH,DELETE. - URL, which can include variables.
- Custom headers with autocompletion for standard ones.
- Body: JSON or raw payload.
- Routing: DNS override, proxy, SSL bypass, cookie preservation, redirect handling.
Response validation
- Status code checks.
- Body and header assertions.
- Variable extraction from the response for use in later steps.
Per-request metrics
Each HTTP request records how long each phase took: DNS lookup, TCP connection, TLS handshake, content generation, transfer, and total. Use it to spot a service getting slower, not just one that fails.
Last updated on