Trace API dependencies.
Chain requests with real data.

Distinguish a data dependency from request order

A dashboard may load a profile, fetch notifications and refresh a chart within the same second. Their order in the network log does not prove that one response supplies the next request. They may be independent calls started by the same screen.

A data dependency is more specific: the project list returns an identifier, and opening a project sends that identifier in a detail request. The useful record includes the producing operation, the response field, the consuming operation and its input location. A repeated match across different records makes that interpretation more convincing.

There is still a distinction between an observed data flow and a mandatory prerequisite. A client that already knows an identifier might call the detail endpoint directly. Your capture shows how this client obtained the value, not every valid way another client could obtain it.

Follow an identifier from a list to a detail view

Start with a small workflow that you can repeat without changing data. Open a project list, select one record, then inspect its details. The following example uses invented records and endpoints:

1. GET /projects
   response:
   { "items": [{ "id": "project_7d8e9f01", "name": "Atlas" }] }

2. GET /projects/project_7d8e9f01
   response:
   { "id": "project_7d8e9f01", "name": "Atlas", "archived": false }

Observed link:
  list response: items[].id
  detail request: project ID in the URL path

Select a second project. Confirm that the detail URL changes to that project’s identifier and that the response describes the selected record. If the value stays constant, you may have identified a workspace identifier or a fixed configuration value instead.

For pagination, the same reasoning applies to a cursor: a list response produces it, then a later list request consumes it. Record where it is sent and when the server stops returning another cursor. Do not substitute a guessed page number for an opaque cursor.

Trace the source manually or with apispy Flow

1. Find the consuming request. Inspect its path, query and body. Choose the value whose origin is unclear.
2. Look back through earlier responses. Search for that exact value and identify the field containing it.
3. Repeat with another record. Check whether the producer-to-consumer relationship persists as the value changes.
4. Record the boundary. Note whether both operations use the same host and browser session, and whether a user choice determines which result is selected.

In apispy, perform the workflow in the analysis browser, select a relevant domain and open Flow. The view reports observed links between operations. The inference looks for distinctive response values reused in later URL paths, query parameters or request bodies. Header inputs are outside this matching process.

Short strings, small numbers and common constants are filtered to avoid connecting unrelated calls. A missing link therefore does not prove independence. Encoded, hashed or otherwise transformed values may also require manual investigation. Use the raw network exchange to resolve those cases.

Pass the identifier between two Postman requests

Once the relationship is understood, you can reproduce it in another API client. In Postman, create a collection with a list request followed by a detail request. Configure baseUrl for your API and its required authentication. The example below expects the illustrative list response above.

Add this to the list request’s Post-response script. It clears an old value before validating the new response, so a previous run cannot silently supply the next identifier.

pm.collectionVariables.unset("projectId");
try {
  if (pm.response.code !== 200) {
    throw new Error("Expected a successful project list");
  }
  const id = pm.response.json().items?.[0]?.id;
  if (typeof id !== "string" || id.length === 0) {
    throw new Error("The list did not return a project ID");
  }
  pm.collectionVariables.set("projectId", id);
} catch (error) {
  pm.execution.setNextRequest(null);
  throw error;
}

Set the detail request URL to {{baseUrl}}/projects/{{projectId}}. The example selects the first result; use the record-selection rule your workflow actually needs. In a collection run, stopping the sequence prevents the next request from using a missing ID. When sending requests individually, verify the list succeeded before sending the detail request.

See Postman’s documentation on reusing variables and controlling collection request order. The setNextRequest function applies to collection execution, not the standalone Send button. Check for an environment variable of the same name if a request unexpectedly uses a different value.

Diagnose a chain that works once and then fails

• An old identifier survives a failed lookup. Clear the stored value before extracting a replacement and stop the sequence when the expected response is absent.
• The first result is not the intended record. Select by an explicit condition and handle empty results. Do not assume list ordering is stable.
• The handle is short-lived or session-bound. Obtain it within the same intended workflow. A copied value may no longer describe an available resource.
• A later request crosses a host boundary. Check the credentials and input format for that host rather than copying the whole browser request indiscriminately.
• The client transforms the value. A URL-encoded, combined or hashed representation may not be an exact string match. Inspect the transformation before documenting it as a direct copy.

Prefer a minimal sequence whose inputs you can explain. A successful replay of twenty copied requests says little about which of them the workflow actually requires.

Document the dependency alongside the schemas

A useful handoff explains the producer field, consumer input, record-selection rule and failure behavior. Include a small example using non-sensitive values, then link to the operation schemas. Keep credentials out of the example; obtain authentication through the client’s normal configuration.

OpenAPI provides a Link Object for describing possible relationships between operations. apispy records its observed input links in x-apispy-inputs extensions on consuming operations. These are not automatically executable workflow steps, and a generic generator may not interpret them.

Export the HTTP operation documentation, preserve the dependency notes, and compare the same workflow in later captures using the API schema drift guide. A changed response field may affect both a client’s data model and the next request it constructs.