# 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](/api-testing/api-chaining.md). ## 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 %} --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://learning.contextqa.com/api-testing/creating-api-tests.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.