How to Replay a Failed API Request on macOS Without Reproducing It

An API call failed once — a 500 deep inside a checkout flow, or a flaky 401 that only shows up sometimes. To see it again the obvious path is to drive the whole app back to that exact state: log in, add the item, click through three screens, and hope it misfires the same way. That is slow, and each attempt costs you the fresh context you had when it broke.

There is a shorter path. If the request was captured, you already have the exact bytes that went over the wire. The outcome of this guide is a tight iteration loop: select the failed flow in Rockxy on macOS, re-send it as-is, edit one field at a time with Compose, and compare each result against the original — without touching the app UI again.

Why replay beats re-driving the app

Reproducing a failure through the UI mixes two unknowns: whether the request itself is wrong, and whether you can get the app back into the state that produces it. Replay separates them. You take the captured request — the real method, URL, headers, query, and body that actually failed — and re-run just that, so the only variable left is the request.

From there, changing one field and re-sending tells you exactly which field mattered. A wrong header value, an expired token, a malformed JSON body, a stale query parameter: each becomes a single-variable experiment instead of another full trip through the app. That is the difference between guessing and bisecting.

What you will need

• Rockxy on macOS 14 (Sonoma) or later. It is a native app; download it from the Rockxy download page.
• The failed request already captured in Rockxy. If it is not, trigger the flow once with capture on so the row exists — you only need it to fail a single time.
• For an HTTPS endpoint, the host inside Rockxy's SSL Proxying scope with certificate trust set up, so the request and response bodies are readable rather than a tunnel.
• Awareness of whether the request is safe to repeat. A GET is harmless; a POST, PUT, or DELETE may cause a real side effect on the server.

Step 1 — Find the failed flow and replay it as-is

Open the traffic list and select the request that failed — the row with the error status you are chasing. Before changing anything, re-send it exactly as captured using Replay/Repeat. This is your control: it tells you whether the failure is deterministic or intermittent.

Two outcomes, both useful:

1. It fails again the same way. The failure is in the request or the server's response to it, not in some transient app state. Good — now you can change one field at a time and watch the status move.
2. It now succeeds. Something was time-bound — a token that has since refreshed, a rate limit that has reset, a race that did not recur. That itself is the finding, and it points you at the moving part rather than the static request.

What you should see in Rockxy: a new row appears in the traffic list for the replayed request, separate from the original. You now have two flows for the same endpoint — the captured failure and your first replay — sitting side by side.

Step 2 — Edit the request with Compose before re-sending

A raw replay reproduces the failure; Compose lets you change it. Open the captured request in Compose and you can edit the method, URL, headers, query parameters, and body, then send that modified version. This is where the single-variable work happens.

Common edits, one at a time:

• Swap an expired token. If the original failed with 401, replace the Authorization header with a fresh value and re-send. If it now returns 200, the request shape was fine and the credential was the whole problem.
• Fix the body. If the server rejected a 400, edit one JSON field — a missing key, a wrong type, an off-by-one id — and send again.
• Change the target. Edit the URL or a query parameter to point at a different resource or a staging host, without rebuilding the whole call by hand.

Because each Compose send produces its own row, you build up a short history of experiments you can read back later. For the mechanics of pausing and rewriting a request live as it happens rather than after the fact, see how to intercept and edit a request with breakpoints on macOS.

Step 3 — Compare the new result against the original

After each edited replay, the question is what actually changed. Rather than eyeballing two response bodies, use Diff Compare: select the original failed flow and your replayed one, and Rockxy lays out the differences between them so you can see exactly which header, field, or status moved.

This closes the loop. Edit one field in Compose, send, diff against the original, read the delta, repeat. A run of small diffs walks you straight to the field that flips the response from failing to passing. The full workflow for reading those differences is in how to compare two API responses with diff on macOS.

Replay from your AI assistant with Local MCP (optional)

The same replay loop is available to an MCP-capable AI tool. Rockxy ships a built-in local MCP server that exposes a replay_request tool, so an assistant like Claude or Cursor can re-send a captured flow — with overrides to the headers, body, or URL — and read the result back, instead of you retyping edits by hand.

Local MCP is 100% free and unlimited in the Free tier. No license upgrade required. The workflow is local-first and user-controlled: Rockxy's MCP server binds to localhost, and captured data stays in a local store on your Mac. Rockxy itself never uploads your traffic to an AI provider. If you enable the workflow, the assistant you connect may include the data it retrieves in its own prompts — that is your choice to make per tool. For a worked example of this loop against a live integration, see debugging a Stripe webhook with Claude.

If it does not work

The replayed request fails where the original passed, or vice versa. A token, nonce, or timestamp in the captured request has expired. A raw replay sends the old value verbatim, and the server rejects it. Open the request in Compose, refresh the time-bound field, and send that version instead.

You see a tunnel row and cannot read the body. That is TLS, not replay. The host is not being decrypted — add it to Rockxy's SSL Proxying scope and confirm certificate trust. If the server pins its certificate, Rockxy will not silently defeat that: a pinned or failed handshake is surfaced as a failed transaction in the request list, so you can see it happened rather than getting a decrypted body.

The replay had a real effect you did not want. Non-idempotent requests do exactly what they say. Replaying a POST that creates an order creates another order; a DELETE deletes again. Point replays at a development or staging environment, and never re-run a mutating request against production unless you know it is safe to repeat.

Limitations to keep in mind

Replay re-sends the request you captured; it does not reconstruct server-side state. If the failure depended on a specific sequence of prior calls, replaying the last request alone will not reproduce it — you may need to replay the earlier steps too. Time-bound values (tokens, nonces, signatures) need refreshing in Compose before a raw replay will pass. And decrypted bodies still require the HTTPS host to be in SSL Proxying scope with certificate trust, exactly as with any captured flow.

Next steps

The loop is short: select the failed flow, Replay it as-is to check whether the failure is deterministic, edit one field in Compose, and Diff Compare the result against the original. Repeat until one change flips the status. You never drive the app again — the captured request is the whole experiment.

From here, go deeper on the two halves of the loop with intercept and edit with breakpoints and compare two API responses with diff, or read the request replay docs for the full feature reference.