Pre-Request and Post-Response Workflows: Chaining Requests Together

Individually, scripting, variables, and assertions each solve one problem. Combined across a request’s full lifecycle — before it sends, and after the response comes back — they let one request set up state that the next request depends on, without any manual copy-pasting between them.

The Lifecycle

Every request runs through the same two hook points:

1. Pre-request script — runs first, can read/write variables and modify the outgoing request.
2. (the actual HTTP call happens)
3. Post-response script — runs after, can inspect the response, run assertions, and write variables for later use.

Common Pre-Request Patterns

• Fetching a fresh token before the call, rather than relying on one pasted in ahead of time and hoping it hasn’t expired:

  // Pre-request script
  if (!pm.environment.get('access_token')) {
    // fetch or refresh, then:
    pm.environment.set('access_token', freshToken);
  }

• Computing something the request needs — a timestamp, a checksum, a value derived from another variable — that can’t just be a static value in the request definition.

Common Post-Response Patterns

• Assertions — verifying the response looks right before treating the data as trustworthy (see Assertions).

• Extracting a value for the next request — the single most useful post-response pattern for chaining:

  // Post-response script, on a "create user" request
  const body = pm.response.json();
  pm.environment.set('user_id', body.id);

  A later request in the same collection can then reference {{user_id}} directly in its URL or body — no manual copying between requests, and it stays correct every time you re-run the sequence.

A Concrete Chain

1. POST /users — post-response script saves body.id as {{user_id}}.
2. GET /users/{{user_id}}/orders — uses the variable the first request just set.
3. That request’s own post-response script asserts the order list came back as an array, and optionally saves the first order’s id as {{order_id}} for a third request.

Each step only needs to know the variable name the previous step produced — not how that value was computed.

A Scoping Note

Pre-request and post-response scripts in HTTP Titan are defined per request, not at the collection level — there’s no single script that runs automatically before every request in a collection. For a chain like the one above, each request’s own script is what does the work; there’s no hidden collection-wide hook running in addition to it.

Building Workflows in HTTP Titan

Set variables in one request’s post-response script, reference them with {{name}} in the next request’s URL, headers, or body, and add assertions at each step to catch a broken chain immediately instead of several requests later. Environment variables persist between runs within that environment, so a workflow you’ve built once keeps working the next time you send the sequence.