# Creating API Tests

{% hint style="info" %}
**Who is this for?** Developers and SDETs who want to create REST API test cases in ContextQA — including importing tests directly from a Swagger or OpenAPI specification.
{% endhint %}

This page walks through creating an API test case from scratch, wiring up variables, and generating tests from a Swagger specification.

## Creating an API test case

1. Click the **plus (+) icon** in the blue bar on the left side of the ContextQA dashboard.
2. Select **Start recording** from the options.
3. Enter a name for your workspace (for example, `API testing`) and click **Create**.
4. In the step editor, type `rest` and select **Rest API method** from the list.
5. Click the **three dots** icon to open the API testing panel.

The panel exposes the following fields:

| Field          | Purpose                                           |
| -------------- | ------------------------------------------------- |
| HTTP method    | Select GET, POST, PUT, PATCH, or DELETE           |
| URL            | The full endpoint URL                             |
| Headers        | Key-value pairs; supports variable interpolation  |
| Body           | JSON or other payload for POST/PUT/PATCH requests |
| Store response | Name of the variable that will hold the response  |
| Validation     | Assertions to run against the response            |

6. Paste your target API endpoint into the URL field.
7. Under **Store response**, enter a variable name such as `result`. The full response object — status code, headers, and body — is stored under this name.
8. In the **Validation** section, configure at least a status code assertion. Choose **status** as the data type, set the comparator to **equal**, and enter `200` as the expected value.
9. Click **Get** or **Send** to test the request interactively and preview the response before saving.
10. Click **Create**, then **Create** again to save the test step.
11. Click **Run** to execute. Open the **execution screen** to confirm the test passed.

## Using variables in API requests

Variables prevent you from hard-coding sensitive values such as tokens, base URLs, or environment-specific hostnames directly into test steps.

### Defining a variable

1. Open your API test case.
2. Click the **variables** option in the test editor.
3. Enter a key (for example, `token`) and paste the value. Click **Create** to save it.

### Referencing a variable

Use `${variable_name}` syntax anywhere in the request configuration:

* **Authorization header:** `Bearer ${token}`
* **URL:** `${BASE_URL}/api/v1/users`
* **Body field:** `"api_key": "${API_KEY}"`

Variable values are resolved at execution time. To rotate a token, update the variable value once — no test steps need to change.

### Variable scopes

* **Local variables** are defined at the test-case level and are available only within that test case.
* **Global variables** are available across all test cases in a project.
* **Runtime variables** are captured from API responses using the **Store response** field and are available to subsequent steps within the same execution.

## Sending the request and capturing the response

When you click **Send** in the API panel, ContextQA executes the request immediately and displays the response body, status code, and headers in the panel. Use this preview to:

* Confirm the JSON structure before writing JSON path assertions
* Copy the exact JSON path to a field (for example, `result.body.email`) for use in payload validation
* Verify that authentication headers are being resolved correctly from variables

After saving the step and running the test case, full response details are accessible in **Run History** under the **Response Body** tab.

## Chaining API calls

When one API step's response must feed into a later step, store the response in a named variable and reference its fields using dot notation.

**Example:** A `POST /auth` call stores its response as `result`. The access token returned in the body is then available as `result.body.access_token`. In the next API step, set the `Authorization` header to `Bearer ${result.body.access_token}`.

For a detailed walkthrough including hybrid API + UI chaining, see [API Chaining](https://learning.contextqa.com/api-testing/api-chaining).

## Generating tests from a Swagger or OpenAPI specification

ContextQA can import a Swagger or OpenAPI file and produce a test case for each endpoint-and-status-code combination defined in the spec.

1. Click the **plus (+) icon** on the ContextQA dashboard.
2. Select **Import File**.
3. Choose **Import Requirement**, then select **API**.
4. Upload your `.json` or `.yaml` Swagger / OpenAPI file.
5. Review the imported endpoints and response codes in the preview panel.
6. Navigate to **Imported Files** and refresh the view to see the generated test cases.

Each generated test case reflects a documented endpoint and expected status code — for example, separate cases for `200`, `400`, `401`, and `500` responses on the same endpoint. You can then edit individual steps to add authentication headers, payloads, and more specific assertions.

This is also available through the `generate_tests_from_swagger` MCP tool, which accepts the same Swagger/OpenAPI content and produces the equivalent test cases programmatically.

{% hint style="info" %}
**Generate API tests from your Swagger spec in minutes.** [**Book a Demo →**](https://contextqa.com/book-a-demo/) — See ContextQA generate and execute REST API tests for your backend.
{% endhint %}