# Reproduce a request from a HAR

Canonical: https://fairleadhq.com/docs/recorder/developers/reproduce-a-request/

Updated: 2026-10-10
Publication state: published
Product version: Source verified — 52de40a

Agent summary: Reconstruct a reviewed request from network.har in a controlled environment. Replay can modify data and does not reproduce browser state.

## Prerequisites

- A recorded request and an authorized test environment

## Inputs

- Reviewed request headers and body

## Outputs

- A controlled reproduction and response comparison

## Limitations

- Replay can modify data and does not reproduce browser state; missing or redacted request data cannot be recovered from the bundle

## Permissions

- Authorization to execute the request in the chosen environment

## Privacy

- Review logs and recorded values before copying or running artifacts


Use captured request evidence in a controlled reproduction.

Reconstruct a request from the supplied `network.har` to investigate it outside the original browser interaction. Review the destination, credentials, and side effects before executing it.

## Extract the request

1. Open `network.har` in a trusted HAR viewer or editor.
2. Find the entry by method, URL, absolute time, subject identifier, or payload value.
3. Inspect its URL, headers, cookies, query values, and `postData` before constructing a command in your HTTP tool.
4. Remove or replace expired credentials and change the destination to an authorized test environment.

Some HAR tools can generate cURL, but inspect their output before execution. Preserve the captured body format rather than rewriting it into a more familiar shape.

## Inspect a request from the sample files

In the [sample investigation](https://fairleadhq.com/docs/recorder/developers/trace-a-failure/#worked-example-the-sticky-blocked-tag), `log.entries[4]` is the POST that moves the card to In progress. Its method, URL, headers, and serialized `postData.text` describe the captured request.

The body wraps `id` and `status` in an application-specific encoding. Replacing it with a plain `{ "id": "…", "status": "in_progress" }` object would change the wire format. Use the target application's client or the correct serialized body for its current build. The captured `/_serverFn/` route may also change between builds.

Start with the read-only comparison: the POST sends no `blocked` field and the subsequent GET retains the blocked value. Replay only if it will answer a remaining question, using your own test card and environment. The sample's creation body is redacted, so it cannot supply complete setup.

## Prepare a safe reproduction

Read the URL, method, headers, and body. Change the destination to an appropriate test environment if necessary. Supply approved test credentials for redacted or expired values. Check cookies and anti-forgery tokens rather than assuming they remain valid.

A replayed request can create, update, or delete data. Confirm the operation and use disposable test records where needed. Do not execute copied commands blindly.

## Compare the response

Run the reviewed request with your HTTP tooling and compare status, response content, and timing with the recorded evidence. Record which inputs or headers you changed.

A cURL request does not reproduce the browser's DOM state or browser-enforced cross-origin behavior. A success outside the browser may therefore narrow the investigation without resolving the original failure.

## Handle incomplete evidence

Missing or truncated bodies cannot be recovered by copying the request. Streaming messages and WebSocket frames are not equivalent to an ordinary request replay. If required context is absent, capture a new focused attempt with suitable rules.

Share the result, original evidence reference, and changed conditions with the investigator. Keep credentials out of the issue and shared command text.