API Chaining

Connect multiple API calls in a single test case by extracting response fields into variables and passing them to subsequent steps — including hybrid API and UI flows.

Who is this for? Developers and SDETs who need to pass data between API calls — such as capturing an auth token and injecting it into subsequent requests or UI steps.

API chaining lets you build multi-step request sequences where the output of one call becomes the input of the next. The most common pattern is authentication: a login endpoint returns a short-lived access token that must be injected into every subsequent request. Because the token expires quickly, you cannot hard-code it — chaining is the correct approach.

Watch the API chaining walkthrough.

ContextQA also supports hybrid chains where a value extracted from an API response is passed directly into a UI interaction, and vice versa.

How chaining works

Every API step stores its full response — status code, headers, and body — in a named variable that you define in the Store response field. The variable is available to every step that follows it in the same test case execution. Fields within the stored response are accessed using dot notation:

result.body.access_token
result.body.firstName
result.headers.content-type

Any subsequent step — API or UI — can reference these paths using ${variable_name.path} syntax.

Practical example: POST /auth then GET /protected-endpoint

Step 1 — Authenticate and capture the token

1. Add an API step. Set the HTTP method to POST and enter the authentication endpoint URL (for example, https://api.example.com/auth).
2. In the request body, supply the login credentials.
3. Under Store response, enter result. This stores the full auth response.
4. In Validation, add a status code assertion: status equal 200.
5. Click Create to save the step.

After the step runs, the access token returned by the endpoint is available as result.body.access_token (adjust the path to match your actual response structure).

Step 2 — Call the protected endpoint with the token

1. Add a second step and choose API.
2. Enter the protected endpoint URL. If the test has an environment, use its base-URL variable from the data picker instead of repeating the host.
3. In Headers, add an Authorization key with the value Bearer ${result.body.access_token}.
4. Under Store response, enter a new variable name, for example result1.
5. Add a status code assertion: status equal 200.
6. Click Create to save.

When the test suite executes, both steps complete. ContextQA resolves the ${result.body.access_token} reference at runtime using the live token from step 1, so the assertion in step 2 passes even though the token value changes between runs.

Hybrid API + UI chaining

Values extracted from an API response can be injected directly into UI actions. This enables data-driven UI tests that do not rely on hard-coded test fixtures.

Example: After the two API steps above, add a UI step that navigates to a web page and enters a value from the API response into a form field.

1. Add a UI step with the Navigate action and enter the target URL.
2. Add another UI step to type into an input field. When entering the value, reference the API response using dot notation — for example, result1.body.firstName.
3. Provide the field's metadata (element label, role, or other locator context) so ContextQA can find it.
4. Click Create to save.

When the test runs, ContextQA reads firstName from the API response captured in result1 and types it into the correct UI element. This confirms that data returned by the API actually appears in the interface.

Extracting specific fields

When constructing a JSON path for chaining, preview or run the producing request first:

1. Select Send Request in the API step to display the response preview.
2. Double-click the response value you want, such as the access token, to copy its JSON path.
3. Use the stored-response variable plus that path in the next step, for example ${result.body.data.token}.
4. After running the full test, open Run History, select the producing step, and use Response Body to verify the path if the dependent request fails.

Business use case: Authenticate once, then reuse the live token across read, update, and delete requests. This verifies the complete service workflow without storing an expiring token in the test definition.

Error handling in chained sequences

If an earlier step in a chain fails — for example, the auth endpoint returns a 401 instead of 200 — ContextQA stops the execution of that test case and marks all downstream steps as not run. This prevents false failures caused by missing variable values rather than actual bugs in the downstream API.

To make a chained sequence robust:

• Always include a status code assertion on the step that produces the variable. A failing assertion surfaces the root cause (the auth step) rather than a confusing downstream error.
• Use descriptive variable names (authResult, userResult) rather than generic names (result, result1) to make step references easier to read and debug.
• When a chain breaks, check Run History for the first failed step — that is where the root cause will be, not in the steps that never ran.

Generate API tests from your Swagger spec in minutes. Book a Demo → — See ContextQA generate and execute REST API tests for your backend.