14 / Reproduce, then reason

Reproduce an API failure with the request and response evidence intact

Move from a vague report to a controlled replay, structural comparison, and shareable investigation that another engineer can follow.

Start debugging Send a request

debug://incident-104reproduced

REPORT→REPLAY→DIFF→CAUSE

FIRST DIVERGENCEresponse.items[3].currencyUSD ≠ null

Working reference

What goes in, what comes out, and what the result can prove.

INPUTFailed request, response, timing and relevant environment context

OUTPUTReproduction, first divergence, hypotheses and next deterministic check

Concrete artifact

Start at the first fact that differs

Expected: 201 Created
Observed: 401 Unauthorized
Evidence: WWW-Authenticate: Bearer error="invalid_token"
First divergence: token expired 43 s before request
Next check: reproduce with freshly issued token

Review sequence

Three checks before the result becomes a decision.

Reproduce

Keep the smallest request that still fails.

Locate divergence

Compare expected and observed status, headers, body and timing.

Test a hypothesis

Change one relevant variable and retain the result.

Limits

What this workflow does not prove.

A plausible explanation is not a confirmed root cause.
Remove secrets and personal data from shared reproductions.
Client, proxy and origin evidence may all be required.

Questions worth answering

Before you put it into a real workflow.

Can I import cURL?

Yes. A cURL command is often the quickest reproducible starting point.

Can I compare JSON responses?

Yes. Structural comparison helps distinguish changed values from changed shape.

How should I handle credentials?

Replace production secrets with scoped test credentials and redact them before sharing an investigation.

Next move

Start with one concrete API problem.

Keep the first step small. Move into a workspace when the result deserves to be saved, repeated, or shared.

Start debugging Talk to a human