Testing API Calls

The API Calls feature allows a web or mobile testing agent to make individual HTTP requests during test execution. This enables data fetching, authentication workflows, integration testing, and API validation alongside an interface test.

To test an API as the primary system under test, create an API application. Its dedicated agent can make multiple requests, execute validation code, and produce an API-focused trace. Use an API Key config for secret tokens, or Custom Fields for non-secret test data.

What Can You Do With API Calls?

Fetch test data or credentials from your backend before testing UI workflows
Authenticate via API to get tokens or sessions for protected pages
Validate data by checking API responses match what you expect

Setup: Creating an API Call Config

API Calls are configured as Configs in your project settings. The URL and request details are stored in the config, so you can easily reuse them across multiple web or mobile tests.

Open Config Settings

Navigate to Settings → Configs in your project dashboard, then click Add config and select API Call Configuration.

Fill the Configuration Form

Complete the form fields:

Field	Description
Config Name	A descriptive name, such as `Get Test User`
URL	Optional complete endpoint URL, such as `https://api.example.com/v1/users`
Method	Any method, GET, POST, PUT, DELETE, or PATCH. Any method lets the agent choose at runtime.
Headers	Optional JSON object containing HTTP headers
Body	Optional request body for POST, PUT, or PATCH

Enter at least one of URL, Headers, or Body.

Save and Assign to Tests

Click Save to create the configuration. You can then assign this config to a web or mobile test in its Settings → Configs panel.

The Headers field must contain valid JSON. The Body field accepts the text payload required by the target API.

Security: Use Test Credentials OnlyWhen used by a web or mobile test, API Call Configurations (including headers, tokens, and request bodies) are:

Stored in your project settings in plain text
Passed directly to AI language models during test execution
Visible in network logs and screenshots

Always use test credentials. Never use production API keys or credentials with sensitive access.

Configuration Examples

Example 1: GET Request with Authentication

This example shows how to fetch user data with an API key. Fill the form fields:

Field	Enter This
Config Name	`Get User Data`
URL	`https://api.example.com/v1/users/123`
Method	GET

In the Headers textarea:

{
  "Authorization": "Bearer your-test-token-here",
  "Content-Type": "application/json"
}

Example 2: POST Request with Body

This example shows how to send data to your API. Fill the form fields:

Field	Enter This
Config Name	`Create Test User`
URL	`https://api.example.com/v1/users`
Method	POST

In the Headers textarea:

{
  "Authorization": "Bearer your-test-token-here",
  "Content-Type": "application/json"
}

In the Body textarea:

{
  "name": "Test User",
  "email": "testuser@example.com",
  "role": "standard"
}

Viewing API Results

When a test runs, you can inspect the full details of every API call made by the agent.

Open the Run Details page for your test.
In the Action Log (the trace view on the left), click on the step where the API call occurred.
Select the network icon in the detail panel.

Available Details

The API Request view provides a comprehensive breakdown:

Summary: Method (color-coded), Status Code, and URL path.
Copy as cURL: A button to copy a debugging command for the request. Sensitive header values may be masked.
Request Details:
- Query Parameters: Parsed list of URL parameters.
- Headers: Full list of request headers.
- Body: The JSON or text body sent.
Response Details:
- Headers: Response headers received from the server.
- Body: The full JSON or text response.

Overriding Config Values

You can instruct the agent to change a path, ID, method, or body at runtime. Treat this as a natural-language instruction, not a deterministic template substitution. Example:

Config: Get User with URL https://api.example.com/users/1
Test step: “Use the Get User config to request /users/555 from the same API host.”

Reuse authorization headers only with trusted endpoints on the same host. Create a separate configuration for another host so credentials are not sent to the wrong service.

Response Format for the Agent

The agent receives the API response in a structured format it can understand and use in subsequent steps:

{
  "statusCode": 200,
  "statusText": "OK",
  "data": {
    "userId": 123,
    "email": "john@example.com"
  }
}

This allows the agent to:

Extract data: “Get the email from the API response and type it into the login form.”
Verify success: “Check that the API returned status 200.”

Limitations

No Variables: Headers and bodies are stored values unless the agent changes them from natural-language test instructions.
Network Access: Without an SSH tunnel, the target must be publicly accessible or allow QA.tech IPs.

For the different network and runtime constraints of first-class API tests, see API Testing.

Get Started

Core Concepts

Configuration

Best Practices

Test Features

Integrations

Applications

CLI

What Can You Do With API Calls?

Setup: Creating an API Call Config

Configuration Examples

Example 1: GET Request with Authentication

Example 2: POST Request with Body

Viewing API Results

Available Details

Overriding Config Values

Response Format for the Agent

Limitations

​What Can You Do With API Calls?

​Setup: Creating an API Call Config

​Configuration Examples

​Example 1: GET Request with Authentication

​Example 2: POST Request with Body

​Viewing API Results

​Available Details

​Overriding Config Values

​Response Format for the Agent

​Limitations

What Can You Do With API Calls?

Setup: Creating an API Call Config

Configuration Examples

Example 1: GET Request with Authentication

Example 2: POST Request with Body

Viewing API Results

Available Details

Overriding Config Values

Response Format for the Agent

Limitations