> ## Documentation Index > Fetch the complete documentation index at: https://docs.qa.tech/llms.txt > Use this file to discover all available pages before exploring further. # API Testing > Test REST and HTTP APIs with an AI agent that writes and runs validation code in an isolated sandbox 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: | Use case | Use this | Why | | ----------------------------------------------------- | ------------------------------------------------------ | --------------------------------------------------------------------------------------------- | | Test an API as the system under test | **API application** | A dedicated agent explores endpoints, runs validation code, and produces an API-focused trace | | Fetch data or call an API during a web or mobile test | [**API Call Configuration**](/test-features/api-calls) | The interface-testing agent makes an individual request as part of a larger user flow | | Interact with a third-party web interface | **Separate web application** | The test needs a browser to use the third party's UI | 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](/core-concepts/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. | View | What it shows | | ----------------- | ---------------------------------------------------------------------------------------------------- | | **Action Log** | Named test actions and the final Passed or Failed summary | | **Terminal icon** | The generated command, exit status, standard output, and standard error | | **Network icon** | Method, URL, status, query parameters, request and response headers, and request and response bodies | | **Copy as cURL** | A debugging command for an individual captured request, with sensitive header values masked | API tests do not produce a live browser stream, screenshots, video, browser console output, or page metadata. ## Runtime and Network Limits | Limit | Behavior | | -------------------- | ----------------------------------------------------------------- | | Protocol | API environment URLs must use `https://` | | Reachability | The API must be reachable from the public internet | | Network access | The sandbox can connect only to the API environment's target host | | Package installation | Package registries are unavailable during the run | | Sandbox lifetime | 10 minutes | | Agent budget | 50 agent steps by default | | Command timeout | 60 seconds by default, up to 5 minutes for a command | | Test settings | Start path and Agent Cache are not used | 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 * [Create an API test](/best-practices/creating-api-tests) * [Organize applications and environments](/core-concepts/applications-and-environments) * [Configure reusable test data](/core-concepts/configs) * [Run tests](/best-practices/running-tests)