Skip to main content
API testing uses a dedicated AI agent to exercise your API without opening a browser or mobile device. The agent translates each test’s natural-language goal, expected result, and steps into HTTP requests and validation code, runs that code in an isolated sandbox, and reports a verdict with a reviewable trace.

​
How API Testing Works

Each API test belongs to an API application. Its environment supplies the base URL, such as https://api.staging.example.com. When the test runs, the agent:
  1. Reads the test’s Goal, Expected Result, Steps, and assigned Configs.
  2. Makes HTTP requests to the configured API host.
  3. Writes and executes code to parse responses and validate status codes, fields, types, and values.
  4. Returns Passed or Failed with a plain-language summary.
  5. Records the commands and HTTP exchanges in the Action Log.
The agent can use shell scripts, Node.js, Bun, or Python. You describe the API behavior to verify rather than writing the test code yourself.

​
Choose the Right API Feature

QA.tech provides two different ways to work with APIs: Create an API application when the API contract is what determines whether the test passes. Use an API Call Configuration when an API request only supports a web or mobile test.

​
What the Agent Validates

The agent treats HTTP responses as test evidence. This includes error responses: a 401 can be the expected passing result for a test that verifies an expired token is rejected. Write tests around observable API contracts:
  • Expected status codes
  • Required response fields and their types
  • Values explicitly named in the expected result
  • Data that can be created and retrieved in a later request
  • Negative behavior for invalid input or missing authorization
Avoid assertions against generated IDs, timestamps, collection ordering, or total counts unless those exact values are part of the contract. The agent can read a generated ID from one response and reuse it in later requests.

​
Authentication and Test Data

Assign Configs under the test’s Settings → Configs panel. Use a Custom Fields config for API keys, authorization values, header values, IDs, and payload data. Give each field a descriptive key, such as Authorization, X-API-Key, or accountId. QA.tech provides each scalar Custom Fields value to the sandbox as an environment variable. The agent-generated code can use those variables when it constructs headers or request bodies without putting the secret value directly in the command trace. In the test instructions, refer to the config by purpose, such as “Authenticate using the configured API credentials.” Do not copy its values into the Goal, Expected result, or Steps.
Use dedicated test credentials with the minimum required access. Do not put credentials directly in a test goal, expected result, or step because those instructions appear in the run trace.

​
Review API Test Results

API runs use the same Action Log as other tests, but replace the browser view with command and request evidence. API tests do not produce a live browser stream, screenshots, video, browser console output, or page metadata.

​
Runtime and Network Limits

The sandbox includes shell tools, Node.js 24, Bun, and Python 3.14. Other command-line tools are not guaranteed, and the agent cannot install missing packages during a run. If the run exhausts its execution budget or the sandbox cannot complete, the result is an Error with no Passed or Failed verdict. Keep each test focused on one API behavior and split long workflows into separate tests.

​
Next Steps