Quick answer: Chaining requests means extracting a value from one response, such as a token or an id, and passing it into a later request, so each step runs against a real value from the previous step. This keeps the scenario connected and avoids hard-coding values that change on every run. The ordered engine carries the variables across steps and asserts at each stage.
Why hard-coded values break a scenario
A flow that depends on a fixed id or token is fragile. Ids are created at runtime, tokens expire, and a hard-coded value that worked yesterday can point at nothing today. If every request is written with literal values, the scenario is not really a chain, it is a set of disconnected calls that happen to share a document.
Extracted variables solve this by taking the value the running system actually returns.
- A login step extracts the access token from its response.
- A create step extracts the id of the new resource.
- A later step reads or updates that exact id using the token.
How a value moves between steps
The scenario is an ordered sequence, and a variable captured at one step becomes available to the steps that follow.
| Stage | What happens |
|---|---|
| Step 1 runs | A request returns a real token or id |
| Variable is extracted | The value is pulled from the response field or header |
| Step 2 references it | The later request uses the variable instead of a literal |
| Assertion runs | The step confirms the response holds the expected fields |
Because assertions run at each step, a missing or malformed variable is caught at the point it is needed rather than failing silently several calls later.
Keep the extraction tied to the real response
A reliable chain depends on extracting from the field that actually carries the value, not from an assumed shape.
- Confirm the response field or header that holds the token or id.
- Extract it after the first step completes.
- Reference that variable in the later request.
- Assert the later response so a bad extraction is visible.
If the source field is missing, the step fails and the run reports the failure at that step. The engine runs connected requests in the main process with streamed progress, so you can watch each variable get captured and used.
Limits and common mistakes
Variables only flow forward in the ordered sequence, so a step cannot use a value that a later step has not produced yet. A common mistake is referencing a variable before the step that creates it, which leaves the request with no value. Order the steps so the extraction always precedes the reference.
A scenario with extracted variables still runs against real requests, not a mock. A mock returns fixed answers and cannot verify that the backend produces the token or id the way the real system does. Scenarios also stay outside the OpenAPI document, with no x-scenarios keys.
Powerduck keeps the extracted variables attached to the ordered steps and shows them in the streamed run, so you can trace a value from the response that created it to the request that consumes it.
Frequently asked questions
What kinds of values get extracted? Tokens, resource ids, and any header or response field a later step needs, such as a cursor for pagination.
Can a later step use a value from any earlier step? Yes, as long as the step that produces the variable runs earlier in the ordered sequence. The variable flows forward, not backward.
What happens if the source field is missing? The step that needs the variable fails and the run reports the failure at that point, rather than sending a request with an empty value.
The bottom line
Extracted variables are what turn a list of requests into a connected flow. Pull a real token or id from one response and pass it into a later request instead of hard-coding values, keep the extraction tied to the real response field, and order every reference after the step that creates it. This keeps a scenario realistic across runs and makes failures point at the exact step where a value was missing or wrong. Continue in the API scenario testing guide.
Top comments (0)