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. The URL and request details are stored in the config, so you can easily reuse them across multiple tests.
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

Complete the form fields:
FieldDescription
Config NameA descriptive name (e.g., “Get Test User”)
URLThe complete API endpoint URL (e.g., https://api.example.com/v1/users)
MethodSelect HTTP method (GET, POST, PUT, DELETE, PATCH). Defaults to GET.
Headers(Optional) JSON object with HTTP headers (paste into the textarea)
Body(Optional) JSON string for the request body (for POST/PUT/PATCH)
3

Save and Assign to Tests

Click Save to create the configuration. You can then assign this config to any test case in the test’s Settings → Configs panel.
The Headers and Body fields use textareas where you paste JSON. The UI will validate your JSON format before saving.
Security: Use Test Credentials OnlyAPI 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:
FieldEnter This
Config NameGet User Data
URLhttps://api.example.com/v1/users/123
MethodGET
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:
FieldEnter This
Config NameCreate Test User
URLhttps://api.example.com/v1/users
MethodPOST
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"
}

​
Viewing API Results

When a test runs, you can inspect the full details of every API call made by the agent.
  1. Open the Run Details page for your test.
  2. In the Action Log (the trace view on the left), click on the step where the API call occurred.
  3. The detail panel will show an API Requests view (indicated by a network icon).

​
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 the exact request as a cURL command for debugging.
  • 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

Why override? You might want to use the same Auth headers but call a different endpoint or use a different ID in the URL. How to override: In your test instructions, simply tell the agent what to change. The agent will use the base config (Headers, Method) but swap out the URL or Body as requested. Example: Config: Get User (URL: .../users/1) Test Step: “Call the API with URL .../users/555” The agent will keep the authentication headers from the config but fetch user 555.

​
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": "[email protected]"
  }
}
This allows the agent to:
  1. Extract data: “Get the email from the API response and type it into the login form.”
  2. Verify success: “Check that the API returned status 200.”

​
Limitations

  • No SSH Tunnel: API calls originate directly from our servers, not through your SSH tunnel.
  • No Variables: Headers and bodies must be static JSON (unless overridden by natural language instructions in test steps).
  • Public Access: APIs must be publicly accessible or allow QA.tech IPs.