How to add an API Call step?

You can add API calls as steps in your automated Test Case.

What You'll Learn

Adding an API step from the test editor or the chat
Configuring HTTP methods, headers, authentication, body, and per-environment parameters
Using the variables menu to insert credentials, project variables, and extracted values
Executing the step and inspecting the response in the Response Inspector
Saving the API response as a variable to reuse in later steps, with assertions and extractions

1. Configure your API call

Add the step

You can add an API step in two ways:

From the editor — Click Add a new step, then in the Step Type dropdown select API Call.
From the chat — Send a prompt like "Add a POST request to https://example.com with a Bearer token and a body containing id and content". Thunders Copilot will create and pre-fill the step for you.

Choose the target environment

Every API step has an environment selector at the top of the form.

Pick Same settings for all environments (the default option) for shared values. This is the baseline config Thunders uses whenever an environment doesn't define its own — leave only this filled in if the URL, headers, body, and auth are identical everywhere.
Pick a specific environment (e.g. Dev, Prod) to define values that only apply there — URL, headers, body, auth, etc.
Priority rule — an environment-specific value overrides the shared one. If no per-environment value exists, Thunders falls back to Same settings for all environments (default).

→ You only need to override the environments where parameters actually differ.

Method & URL

Pick the HTTP method (GET, POST, PUT, PATCH, DELETE) and enter the endpoint, e.g. https://jsonplaceholder.typicode.com/posts/1.

Parameters

Add query-string parameters with the Add Row button. Each row is a key/value pair.

Headers

Add request headers the same way — for example Content-Type: application/json.

Authentication

Choose one of:

No Auth — no Authorization header sent.
Basic Auth — username + password.
Bearer Token — token value.

Password and token fields are hidden by default. Click the eye icon to reveal.

Request Body

Pick the body format that matches your endpoint:

Raw JSON — paste a JSON payload (used for POST / PUT / PATCH).
URL-encoded — add key/value pairs, sent as application/x-www-form-urlencoded.

Variables in request fields

Type [ or / in the URL, header values, parameter values, auth fields, or URL-encoded body values to open the variables menu. You can:

Insert an existing project variable, credential, or extracted variable.

Create a new variable inline without leaving the step.

Raw JSON bodies use the [VARIABLE_NAME] syntax directly.

Save response as

The full API response is automatically saved into a variable so later steps can reuse it. The Save response as field is pre-filled (API_RESPONSE_1, API_RESPONSE_2, …). Rename it to something descriptive like LOGIN_RESPONSE when it matters. Full reuse syntax is covered in section 4.

2. Example: using variables and credentials in an API step

💡 You can create credentials and variables inline. While editing an API step, type [ or / in any supported field (URL, header values, parameter values, auth fields, or URL-encoded body values) and pick Create new variable from the menu — no need to leave the test case. The environment page is also useful for managing existing values in one place.

Imagine you want to register a new user via an API that needs an API key in the Authorization header and a username / email / password in the body.

Create the credentials and variables

Either inline from the API step (callout above), or in the environment / project settings page:

A credential named API_KEY — your real API key.

A variable named USER_EMAIL — the login email used in the request body.
A credential named PASSWORD — the login password used in the request body.

→ See Add / Edit / Delete / Use Secrets and Variables for the dedicated guides.

Reference them in your API step

Environment: Same settings for all environments
Method: POST
URL: https://api.thunders.ai/api/v1/users
Headers: Content-Type: application/json
Authorization: Bearer Token → [API_KEY]
Body (Raw JSON):

{   "username": "user",   "email": "[USER_EMAIL]",   "password": "[PASSWORD]" }

When Thunders executes the step, [API_KEY], [USER_EMAIL], and [PASSWORD] are substituted from the active environment.

Why this matters:

Security — secrets are never hardcoded in test cases.
Maintainability — update credentials once in the environment, and every step that references them picks up the change.
Flexibility — switch active environments to point the same tests at dev, staging, or production.

Execute and inspect the response

Click Execute to run the test case. Once the API step finishes, the step row shows a compact summary:

HTTP method badge, URL, and duration
A Response card with status, latency, and item count (e.g. 200 ok · 63 ms · 100 items)
The line "Full API response stored in [API_RESPONSE_1]

Click the API step row to open the Response Inspector in the main viewer:

Metric cards — Status code, Duration, Load Duration
JSON tree — expand and drill into the response body
Copy — copy the full response to your clipboard
Assert / Extract — one-click buttons on each metric card and JSON value to turn a value into an assertion step or an extracted variable

→ Full walkthrough of assertions and extractions: API Response Assertions and Variable Extraction

Save the response and reuse it

Every API step automatically saves the entire response in the variable named in Save response as (default API_RESPONSE_N). Later steps can reference it directly.

Naming rules — uppercase letters, digits, and underscores; must start with a letter (regex ^[A-Z][A-Z0-9_]*$).

Reference syntax in any variable-aware field of any later step:

[LOGIN_RESPONSE] — the full response object
[LOGIN_RESPONSE].body.token — drill into the JSON body
[LOGIN_RESPONSE].statusCode — HTTP status code
[LOGIN_RESPONSE].duration — request duration (ms)

You can use these inside a later API step's URL or headers, in a browser assertion, in a conditional, and anywhere else that accepts variables.

Login

Execute and extract accessToken into [ACCESS_TOKEN] variable

Use [ACCESS_TOKEN] variable in the next API call to identify the user

Resume the execution

→ To assert on response values and extract individual fields into their own variables, see the dedicated guide: API Response Assertions and Variable Extraction