Skip to main content
The API Calls feature allows your AI agent to make HTTP requests to external APIs during test execution. This enables data fetching, authentication workflows, integration testing, and API validation.

​
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. Here’s how to create one:
1

Open Config Settings

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

Fill the Configuration Form

You’ll see a form with these fields:
  • Config Name: A descriptive name for this API configuration (e.g., “Get Test User”)
  • URL: The complete API endpoint URL (e.g., https://api.example.com/v1/users)
  • Method: Select HTTP method from dropdown (GET, POST, PUT, DELETE, PATCH) - defaults to GET
  • Headers: A textarea where you paste JSON with HTTP headers
  • Body: A textarea where you paste JSON for POST/PUT/PATCH request bodies
3

Save and Assign to Tests

Click Save to create the configuration, then assign it to your test cases under test Settings → Configs
The Headers and Body fields are textareas where you paste JSON strings (such as from the examples below). The UI will validate that your JSON is properly formatted before saving.
Security: Use Test Credentials OnlyAPI call configurations (including headers, tokens, and request bodies) are:
  • Stored in your project settings
  • Passed directly to AI language models during test execution
  • Not encrypted and not hidden from the AI
Always use test credentials with limited permissions. 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:
FieldEnter This
Config NameGet User Data
URLhttps://api.example.com/v1/users/123
MethodSelect GET from dropdown
In the Headers textarea, paste this JSON: 
{
  "Authorization": "Bearer your-test-token-here",
  "Content-Type": "application/json"
}
The Headers field is a textarea where you paste a JSON object. Each key-value pair becomes an HTTP header in the request.Common headers:
  • Authorization: For API keys, bearer tokens, or basic auth
  • Content-Type: Usually application/json for JSON APIs
  • Accept: Tells the API what format you want back
  • Custom headers: Any header your API requires (e.g., X-API-Key, X-Tenant-ID)

​
Example 2: POST Request with Body

This example shows how to send data to your API (e.g., creating a new user, submitting a form, or posting a record). Fill the form fields:
FieldEnter This
Config NameCreate Test User
URLhttps://api.example.com/v1/users
MethodSelect POST from dropdown
In the Headers textarea: 
{
  "Authorization": "Bearer your-test-token-here",
  "Content-Type": "application/json"
}
In the Body textarea: 
{
  "name": "Test User",
  "email": "[email protected]",
  "role": "standard"
}
The Body field is only used for POST, PUT, and PATCH requests. It’s ignored for GET and DELETE.

​
Example 3: Minimal Configuration

If your test needs to check whether an API endpoint is responding (e.g., verify your backend is up before testing UI features), you only need URL and method:
FieldEnter This
Config NameHealth Check
URLhttps://api.example.com/health
MethodGET
Leave Headers and Body empty. During the test, the agent will call this endpoint, receive the response (e.g., {"status": "ok"}), and can verify the service is available before proceeding with UI interactions.

​
How It Works

Once you create and assign an API Call config to a test:
  1. The agent detects the config is available
  2. During the test, the agent makes the HTTP request
  3. The agent receives the response (status code, headers, and data)
  4. The agent uses the response to continue the test
The agent can only make API calls if you’ve assigned an API Call config to the test under Settings → Configs.

​
Overriding Config Values in Test Steps

Why override? If you need to call the same API with different parameters in different test steps (e.g., fetching different user IDs, different query parameters, or different request bodies), you can override values without creating multiple configs. Example scenario: You have one “Get User” config, but your test needs to fetch multiple users. Your base configuration:
  • URL: https://api.example.com/users
  • Method: GET
  • Headers: {"Authorization": "Bearer token123"}
In your test steps, you can instruct the agent:
  • Step 1: “Call the API with URL https://api.example.com/users/123” → Fetches user 123
  • Step 2: “Call the API with URL https://api.example.com/users/456” → Fetches user 456
The agent uses the overridden URLs while keeping the configured headers and method. This saves you from creating separate “Get User 123” and “Get User 456” configs.

​
Response Format & Using Response Data

The agent receives API responses in this format: 
{
  "statusCode": 200,
  "statusText": "OK",
  "data": {
    "userId": 123,
    "name": "John Doe",
    "email": "[email protected]"
  }
}
The response includes:
  • Status Code: HTTP status (200, 404, 500, etc.)
  • Status Text: Status message (“OK”, “Not Found”, etc.)
  • Data: Parsed JSON response body (or raw text for non-JSON responses)
  • Headers: All response headers are captured and available

​
What the Agent Does With Responses

The AI agent can use the API response data to continue the test workflow: Example 1: Use response data in the browser
  • API returns: {"email": "[email protected]", "password": "temp123"}
  • Agent extracts the email and password from the response
  • Agent then enters these credentials into the login form in the browser
Example 2: Verify response data
  • API returns: {"orderId": "ORD-456", "status": "pending"}
  • Agent checks that the order was created successfully (status code 200)
  • Agent can verify the orderId exists and status is correct
  • Then proceeds with the rest of the test
Example 3: Check API errors
  • API returns: {"statusCode": 404, "statusText": "Not Found"}
  • Agent detects the failure and reports it in the test results
  • Test can fail if the expected API is not available

​
Limitations

  • API calls do not respect SSH Tunnel Proxy and instead go directly from our servers, not through your SSH tunnel.
  • Headers and request bodies must be manually configured (no variables or templating)
  • Failed requests are not automatically retried
  • APIs must be publicly accessible or allow QA.tech IPs