Stored Results and Comparison

Hook keeps the response of every request it runs, not just a record that the request happened. A past run can be reopened in full, and any two runs can be compared side by side.

What gets stored

When a request completes, Hook writes the response to the result store: status line, response headers, body, and the timing breakdown. The matching history entry records the id of that result, which is how the two are tied together.

Storage is on by default. Turn it off, or change how much of each body is kept, in the Settings tab:

A truncated result is still useful: it compares on its first bytes, the status line reads [stored, truncated] and the log says so when you open it. Its JSON no longer parses, so Hook re-indents it on punctuation alone rather than leaving it on the single line it arrived on – see “Pretty body view” in the Requests guide. Nothing is silently dropped.

Cancelled requests are not stored, and neither is anything that never produced a response.

Reopening a past run

Click any entry in the History list. Hook restores the request as it always has, and now also loads that run’s stored response back into the response panel. The status line shows [stored] so a reloaded response is never mistaken for one that just arrived. Sending a new request replaces it and clears the mark.

Entries with no stored result – runs made before you enabled storing, or made by an older version of Hook – restore the request and leave the response panel empty. It is not left showing the previous run: a body that belongs to another request is worse than no body at all.

Comparing two runs

Press Compare under the History list to open the Results window.

Runs are grouped by method and URL, so repeated calls to the same endpoint sit together under one heading, newest first. Expand a group, select a run, and press Set A; select another and press Set B. Swap exchanges the two sides without re-picking them.

The Compare dropdown chooses what is being compared:

• Body – a line-by-line diff of the two response bodies. When both sides have a pretty-printed form (JSON, XML, HTML, JavaScript) the diff runs on that, so a document served on a single line still compares field by field instead of as one big changed line. Comparing a JSON run against a truncated one works the same way: the two are re-indented by the same formatter first, so only the fields that actually differ are reported. Output is cut into hunks with a few lines of context around each change.
• Status + headers – the status line and the response headers. This is where a changed Content-Type, or a caching header that stopped being sent, shows up when the bodies look identical.
• Request – the two request definitions: method, URL, headers, parameters, body, auth, timeouts, redirects, backend. Answers “what did I send differently” rather than “what came back differently”. Auth values are shown as they are, the same way the Auth tab shows them.
• Timings – one row per phase (DNS, TCP, SSL, waiting, download, …) with both runs’ durations and the delta, so a slowdown can be attributed to the part that actually got slower.

Removed lines are red, added lines green, hunk headers blue, in every theme.

The diff view does not wrap. When a line runs past the window a horizontal scrollbar appears along the bottom; drag it, or pan with a tilt wheel (Shift + wheel), to read the rest.

The two pinned runs stay pinned while you switch modes, and they survive the history growing or being trimmed underneath them: each slot holds its own copy of the response.

If two runs are so far apart that Hook cannot match them line by line, the diff says so at the top and shows the whole differing region as removed-then-added. That is coarser, but it never claims a match that is not there.

Where results live and when they are deleted

Results are one JSON file per run, under history/results/ next to the history file:

history/
  hook.ndjson                Request history log
  results/
    20260731-101500-000.json One stored response per run

A result is deleted whenever the history entry that names it goes away:

• Clear Line removes an entry and its stored response.
• Clear All empties the history and the result store together.
• The oldest entries falling past the history limit take their responses with them.
• At startup, Hook deletes any result file no history entry refers to. That collects results orphaned by a crash between storing a response and recording the run.

So the store is bounded by the history limit; it never grows on its own. To reclaim the space immediately, clear the history.

The pretty-printed form of a body is not stored – it is rebuilt when a result is loaded. That halves what each result costs on disk and means a reloaded response is formatted exactly like a live one.