How to Compare Two API Responses on macOS with Diff Compare

"It worked yesterday." The same endpoint, the same request, and now something downstream breaks. Or the call returns one shape on staging and a different shape on production, and you cannot tell why. You open two JSON blobs side by side in a text editor, your eyes glaze over at line 40, and you still are not sure whether a field moved, a value flipped, or a header quietly changed.

Eyeballing two responses does not scale past a few fields. The outcome of this guide is a precise answer instead: capture two flows in Rockxy on macOS, run Diff Compare, and read the exact deltas across status, headers, JSON body, and timing — in place, with the changed fields marked. No copy-paste, no external diff tool, no guessing which of forty lines actually moved.

What Diff Compare actually does

Diff Compare takes two captured flows and shows you what differs between them. Not two files you paste in — two requests Rockxy already recorded. It lines up the pair and surfaces the differences across four axes at once:

• Status — a 200 that became a 500, or a 200 that became a 301.
• Headers — a changed Content-Type, a missing Cache-Control, a different Set-Cookie.
• Body — including structured JSON, so a renamed key, a changed value, or an added array element is highlighted where it sits in the tree rather than as a wall of raw text.
• Timing — the two responses' durations, so a regression that is "correct but slow" does not slip past.

Because the comparison runs on the real captured pair, the thing you are reading is what actually crossed the wire, not a reconstruction you assembled by hand. For the exact click-path to open the view, see the Diff Compare docs.

What you will need

• Rockxy on macOS 14 (Sonoma) or later. It is a native app; download it from the Rockxy download page.
• Capture working for the endpoint you care about. If nothing shows up when you send a request, fix that first with Why Localhost Traffic Isn't Showing in Your Proxy on macOS.
• For HTTPS endpoints, the host must be in Rockxy's SSL Proxying scope with certificate trust in place — otherwise you get a tunnel row with no readable body, and there is nothing to diff. The setup lives in the certificates and trust docs.
• A way to produce the second response — re-running the call, or replaying the first request against a second environment. More on that below.

Step 1 — Capture the baseline flow

Send the request whose behavior you trust — the "yesterday" version, the staging version, the last-known-good run. As long as capture is on and the host is in scope, it lands as a row in the traffic list. That row is your baseline; do not clear the list before you have the second one.

If the endpoint is HTTPS and you see a CONNECT or tunnel-only row instead of a readable body, decryption did not happen. Add the host to SSL Proxying scope and confirm certificate trust before continuing — a diff of two undecrypted tunnels tells you nothing.

Step 2 — Produce the second flow

You need a second captured flow to compare against the baseline. There are two reliable ways to make one.

Re-run the call. If you are chasing a response that drifts between runs — a non-deterministic body, an intermittent error, a value that changes when it should not — just make the same request again. The second capture lands as its own row.

Replay or Compose against a second target. If you are comparing two environments or two deploys, take the captured request and send it again with an edited base URL. Rockxy's Replay re-sends a captured request as-is, and Compose lets you edit the method, URL, headers, query, and body before sending — so you can point the exact same request at production instead of staging and capture the result. Each send produces a new flow in the list.

One caution: replaying a request has real side effects if the request is not idempotent. Re-sending a POST that creates an order, charges a card, or sends a message will do it again. Diff the responses of read calls freely; be deliberate about replaying writes.

Step 3 — Select the two flows and open Diff Compare

With both flows in the list, select the two you want to compare and open Diff Compare on them. Rockxy aligns the pair and renders the deltas in place. For the precise selection gesture and where the action lives in the current build, follow the Diff Compare docs — the UI is the source of truth and it is a click-path, not a command.

What you should see in Rockxy: a two-column comparison with the shared fields shown as unchanged and the differences marked. If a value flipped, you see the old value against the new one. If a JSON key was added or removed, it is flagged at its position in the structure. If the status or a header changed, that line stands out. The screenshot below shows the four axes — status, headers, JSON body, and timing — reported together for a single pair.

This is the payoff. The question "what actually changed between these two responses?" now has a literal answer on screen, and the answer took a selection and a click rather than a manual read of two payloads.

A reproducible loop for chasing regressions

Put the three steps together and you get a tight loop for "it worked yesterday" bugs:

1. Capture the good response as the baseline flow.
2. Produce the bad response — re-run the call, or replay the captured request against the other environment with an edited base URL.
3. Diff Compare the two flows and read the marked deltas.

Because both sides are real captures, the loop is repeatable: change one variable, capture again, diff again. A drifting field narrows to a single key. A staging-versus-production discrepancy narrows to the exact header or status that differs. You stop arguing about which response is "right" and start reading what is different.

Diff two flows from your AI assistant (optional)

Once both flows are captured, you do not have to open the view yourself. Rockxy ships a built-in local MCP server whose tools include list_flows, get_flow_detail, replay_request, and diff_flows. An MCP-capable assistant like Claude or Cursor can call diff_flows on the two flow ids and describe the differences in plain language, so you can ask "what changed between these two responses?" and get an answer against the real captures instead of pasting payloads into a chat.

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. Setup is in the Connect Claude Desktop to Rockxy guide.

If it does not work

You cannot start a comparison because a flow is missing. Diff Compare works on two flows you have already captured. Both rows must exist in the traffic list before you begin — there is no "diff against a saved file" here. If the second response never landed, capture it first, then select the pair.

The body diff is empty or shows only a tunnel. The response was not decrypted, so there is no body to compare. For HTTPS, add the host to SSL Proxying scope and confirm certificate trust, then re-capture both flows. A pinned or failed handshake will surface as a failed transaction rather than being silently decrypted — Rockxy does not defeat certificate pinning.

The two flows look unrelated. Confirm you selected the intended pair. If you replayed against a second environment, check that only the base URL changed and the rest of the request matched — an accidental method or body edit in Compose will show up as a difference that is really your own change, not the server's.

Your replay had side effects. If producing the second flow created data, charged something, or sent a message, that was a non-idempotent replay doing its job twice. For write endpoints, prefer re-running against a disposable environment, or compare two naturally captured flows instead of replaying.

Limitations to keep in mind

• Diff Compare operates on two flows that already exist in the capture list. It is not a diff of arbitrary files or of a live request against a stored snapshot — capture both sides first.
• For HTTPS, body-level diffing requires decrypted bodies. Without the host in SSL Proxying scope and certificate trust in place, you can only compare metadata, not payloads.
• Replaying non-idempotent requests to manufacture the second flow can mutate real state. Treat write replays as real requests, because they are.

Next steps

The rule is short: capture two flows, run Diff Compare, read the marked deltas. Two JSON blobs stop being a staring contest and become a list of exactly what moved.

From here, pair diffing with the rest of the debugging loop. If capture itself is the problem, start with Why Localhost Traffic Isn't Showing in Your Proxy on macOS. To understand why keeping the evidence on your own machine matters for this kind of work, read Local-First Network Evidence for Debugging on macOS. To let an assistant read and diff captures for you, set up Connect Claude Desktop to Rockxy. The exact click-paths live in the Diff Compare and Replay docs.