TestInspector supports API testing through HTTP request steps that send GET, POST, PUT, PATCH, and DELETE requests to any reachable endpoint, with configurable headers, request bodies, and assertions on status codes and response body content — all defined in the step editor without writing code. A test that calls an API endpoint, validates the response, and continues to the next step requires only selecting the method, entering the URL, and specifying what the response must contain. The same test can chain multiple API calls, inject dynamic values from TestInspector's variable system into request bodies and headers, and combine API steps with browser-driven UI steps in a single continuous test flow.

What HTTP Request Steps Do and How They Work

An HTTP request step in TestInspector sends an outbound network request from the test execution engine and evaluates the response against configured assertions. The step is configured with four components: the HTTP method, the endpoint URL, optional request headers as key-value pairs, and a request body for POST, PUT, and PATCH requests. After the request completes, TestInspector evaluates each configured assertion — status code, full body content, or specific JSON path values — and marks the step as passed or failed based on all assertions together.

HTTP request steps execute outside the browser context. Unlike browser-driven steps that run through Selenium and are subject to same-origin policy and CORS restrictions, HTTP request steps are direct network calls from the TestInspector execution engine. This means they can reach internal APIs, admin endpoints, and services not exposed through any browser-facing interface. A test running against a staging environment can call both the browser UI and the internal REST API in the same test definition, verifying not just what the user sees but what the underlying system actually recorded.

Execution order is sequential and follows the same step ordering as any other TestInspector test. An HTTP request step can appear before, after, or between browser interaction steps. This enables patterns like: call an API to create test data before the UI flow runs, execute the browser steps, then call an API to verify the backend state reflects the UI action. This combination of API setup, browser interaction, and API verification in a single test is more efficient than maintaining separate API and UI test suites that cover the same flow independently.

When an HTTP request step fails — because the request itself errors, or because an assertion does not match — TestInspector's run report shows the full request sent (method, URL, headers, body), the full response received (status code, headers, body), and the specific assertion that failed. This makes it straightforward to determine whether the failure is a test configuration issue, an environment problem, or an actual API regression. For a broader view of how API testing fits within a test automation program, see Astaqc's test automation services and the complete software testing guide.

Supported HTTP Methods and Assertion Types

TestInspector's HTTP request steps support GET, POST, PUT, PATCH, and DELETE — the five methods covering the complete set of CRUD operations for REST API testing. Each method is configured identically in the step editor; the differences are in which request components are applicable and what assertions are typically meaningful for each method.

Assertions operate at three levels. The first is the status code: assert the response code equals a specific value or falls within a range. The second is full body content: assert the response body string contains a specific substring. The third is JSON path assertion: navigate to a specific field within a JSON response using dot notation and assert its value — for example, assert data.user.role equals "admin".

Multiple assertions can be attached to a single HTTP request step, and all must pass for the step to pass. A POST step that creates a user can assert simultaneously that the status is 201, that the response body contains the submitted email address, and that the id field is non-empty — all in one step configuration, without needing to split validation across multiple steps.

Headers in HTTP request steps accept static values and variable interpolation. Authorization headers are the most common use case: write the header value as Bearer {{AUTH_TOKEN}}, and the variable resolves at execution time from the test, suite, or organization variable scope. The same mechanism works for API keys, custom tracking headers, and any other header values that differ between environments. For guidance on structuring API test coverage, see Astaqc's software testing services and the manual vs. automated testing guide.

Using Variables in API Tests: Dynamic Values, Timestamps, and Encrypted Storage

TestInspector's variable system applies to HTTP request steps in exactly the same way it applies to browser interaction steps. Variables are referenced using double-brace syntax — {{VARIABLE_NAME}} — and can appear in the URL, any header value, and the request body. At execution time, the variable resolves to its current value from the scope hierarchy: test-level variables override suite-level variables, which override organization-level variables.

Three built-in variable types are particularly useful in API tests. The {{TIMESTAMP}} variable inserts the current Unix timestamp at execution time, useful for generating unique values in POST request bodies — a user email written as user_{{TIMESTAMP}}@test.example.com produces a unique address on every run, preventing conflicts from repeated test execution against the same data store. The {{ALPHANUMERIC}} variable inserts a random alphanumeric string, serving a similar purpose for IDs, usernames, and other fields that must be unique per run.

The {{TOTP:secret}} variable generates a time-based one-time password from the provided base32 secret. This is directly applicable to API tests that authenticate against endpoints requiring TOTP as a second factor. Instead of maintaining a separate TOTP generation script, the variable resolves to the correct current TOTP value at the exact moment the authentication API request step executes.

Encrypted variables — stored at any scope level with the encrypted flag set — are decrypted at execution time but never displayed in run reports, logs, or exports. This makes them appropriate for API credentials, bearer tokens, and secrets that should not appear in plain text in test history. An API key stored as an encrypted organization-level variable is available across all tests and suites in the organization, resolved silently at runtime, and never exposed in run output. For more on TestInspector's data management capabilities, see TestInspector's feature documentation and the guide to outsourcing QA.

Chaining API Requests: Passing Response Values to Subsequent Steps

Many API test scenarios require passing a value from one response into a subsequent request. A login step returns an access token that must go into the Authorization header of every following request. A POST step that creates a resource returns an ID that must be used in the GET, PUT, and DELETE steps targeting that resource. These chains require extracting a value from one response and making it available to later steps.

TestInspector handles this through response value extraction combined with its variable system. An HTTP request step can be configured to extract a value from the response — using a JSON path expression for JSON responses — and assign it to a named variable. Subsequent steps in the same test reference that variable using the {{VARIABLE_NAME}} syntax in their URL, headers, or request body. The extraction and assignment happen at step execution time, so the value reflects the actual response from that run.

A practical example: a test that creates, reads, and deletes a user record through the API configures the POST /users step to extract the id field from the JSON response into a variable named CREATED_USER_ID. The subsequent GET /users/{{CREATED_USER_ID}} and DELETE /users/{{CREATED_USER_ID}} steps use that extracted ID automatically. Each test run creates a fresh user, reads it, and deletes it, with the ID flowing through the step chain without any hardcoding.

This chaining pattern also works across the API-UI boundary. A test can use an HTTP request step to authenticate via the API, extract the session token, set it as a header in a subsequent API step, and use the same authenticated state to drive browser UI steps — combining API efficiency for setup with browser-level testing for user-facing behavior. For teams building end-to-end testing strategies that span both API and UI layers, see Astaqc's QA team service and Astaqc's test automation services.

Mixing API Tests and UI Tests in a Single TestInspector Suite

One practical advantage of TestInspector's approach to HTTP request steps is that API and browser-driven steps share the same test definition format. A single test can interleave API calls and browser interactions without switching tools, managing separate frameworks, or coordinating execution order across two systems. The step sequence determines execution order; API and browser steps can appear in whatever order serves the test scenario.

This is most useful for three patterns. First, API-driven setup with UI verification: use API calls to create test data directly (faster and more reliable than creating it through the UI), then run browser steps that verify the UI displays that data correctly. This avoids the slowest part of UI test setup — filling forms through the browser — while preserving UI coverage for the behavior that actually matters.

Second, UI action with API verification: drive the user flow through the browser, then issue an API call to confirm the backend state reflects the action. A checkout flow test can end with a GET request to the orders API, asserting that an order record with the expected items was created. This validates both UI behavior and data persistence in a single test run.

Third, API-driven teardown: after a UI test creates data through the browser, an API call at the end of the test deletes the created resources, leaving the environment clean for the next run. This is more reliable than UI-based teardown because API calls are less susceptible to UI instability in test environments.

TestInspector's scheduling and CI/CD trigger features apply equally to suites containing only API tests, only UI tests, or a mix of both. A mixed suite can be scheduled to run nightly against staging or triggered from a CI pipeline on each deployment. For teams that want to structure test portfolios spanning both API and UI layers, see Astaqc's test automation services, Astaqc's software testing services, and the AI in software testing guide.

Frequently Asked Questions

Can TestInspector send requests to APIs that require client certificate authentication?

HTTP request steps currently support header-based authentication (Bearer tokens, API keys in headers) and request body authentication (credentials in a JSON body or form-encoded login parameters). Client certificate authentication — where the client presents an X.509 certificate as part of the TLS handshake — is not currently supported in HTTP request steps. Teams using mutual TLS at the API layer would need to handle certificate-level authentication at a gateway or proxy layer before the request reaches TestInspector's execution environment.

Does self-healing apply to HTTP request steps?

TestInspector's self-healing capability applies to browser-based element selectors — CSS selectors, XPath, and element attributes used in browser interaction steps. HTTP request steps do not use element selectors, so the self-healing selector suggestion mechanism does not apply to them. The reliability mechanism for API steps is variable-based parameterization: using variables for IDs, tokens, and dynamic values prevents steps from being hardcoded to values that become stale between runs.

How does TestInspector handle large JSON response bodies in assertions?

JSON path assertions navigate to specific fields within the response body, so the size of the overall response body does not affect assertion performance. The assertion evaluates only the field at the specified path, not the complete body. For very large response bodies, JSON path assertions are preferable to full body string assertions, which compare the entire response as a string and are sensitive to field ordering and whitespace differences in JSON serialization.

Can HTTP request steps follow HTTP redirects automatically?

By default, TestInspector's HTTP request steps follow standard HTTP redirects (3xx responses) and evaluate assertions against the final response after all redirects are resolved. If a test scenario requires asserting on the redirect itself — for example, verifying that a 301 redirect to a specific URL is present — this requires asserting on the intermediate response before the redirect is followed, which can be configured by disabling redirect following for that step.

Can TestInspector export API tests to Playwright or Selenium IDE format?

TestInspector exports tests to Playwright TypeScript, Selenium IDE (.side), and Gherkin formats. The Playwright and Selenium IDE exports cover browser-driven steps; HTTP request steps, which execute as direct network calls outside the browser, are not represented in these export formats because neither framework has a native equivalent HTTP step type. Teams that want a portable specification of their API test logic can use the Gherkin export, which produces human-readable feature descriptions of each step suitable as specifications for code-based API tests. See the manual vs. automated testing guide for context on choosing between no-code and code-based approaches.

Is there a limit to the number of HTTP request steps in a single test?

There is no documented fixed limit on HTTP request steps per test in TestInspector. Practical constraints are execution time and response handling — tests with many API calls take longer to run. For API-heavy scenarios, organizing related API calls into modular tests within a suite, rather than placing all calls in one long test definition, produces more granular failure reporting and easier maintenance. See TestInspector's documentation for current configuration options and any updated limits.