Reopening from history

Clicking an entry in the history list opens it as a new request tab. The captured request is loaded into the request area, and the stored response is available in the response panel.

How it works

1. Click an entry in the sidebar's History section (see Sidebar and tabs for where the list lives). A new tab appears in the request area.
2. The tab's name is the history entry's stored name (usually <METHOD> <URL>).
3. The request area is populated with the captured method, URL, headers, params, body, and auth.
4. The response panel is populated with the stored response: status, duration, size, headers, and the body (if one is stored).
5. The tab is not linked to any saved request. Its name is editable and its content can be modified and saved into any collection.

The new tab starts with a dirty dot, since the request has been opened and is ready to edit. Saving creates a new request in the currently selected collection.

What is preserved

Everything that was sent and received is preserved, modulo secrets:

• Method, URL, headers, query params
• Body (including multipart form data, with files referenced by attachment ID — the files are still on disk)
• Auth configuration (with secrets masked; see below)
• Response status, headers, duration, size
• Response body (if storageState: "stored")

The entry's createdAt is shown in the document bar's status field as a starting reference, but the tab itself is treated as a fresh unsaved request.

What is masked

History entries have secrets redacted before they're persisted. Specifically:

• Authorization, Proxy-Authorization, Cookie, Set-Cookie, and any header named X-API-Key is replaced with ••••••••
• Bearer tokens, Basic passwords, API key values, and OAuth client secrets / access tokens are replaced with ••••••••
• URL-encoded form fields whose key matches password|secret|token|authorization|cookie (case-insensitive) are masked
• Multipart text fields with the same key pattern are masked

The masking happens at write time, not at read time. Once a value is in history, it is the masked version. The unmasked value lives only in the environment and the request area. The same masking rules apply to live request fields documented in Cookies and network.

Re-sending

Once the entry is in a tab — landing in the request area — you can re-send it as-is with Ctrl+Enter or Send. Useful for replaying a flaky request or repeating a setup call.

Variables in the captured request are not re-resolved against the current environment — the stored URL is the URL that was actually sent, with the values that were actually substituted. If you re-send, the server re-runs prepareRequest against the current environment, so the new request can resolve to different values if your variables have changed.

Deleting one entry

Hover over the row in the History list and click the trash icon. The entry is removed immediately. The corresponding response body file (if any) is removed on the next retention pass.

What's next?

• Viewing and filtering history — the rest of the history list's behavior
• Saving and tabs — turning an opened history entry into a saved request
• Variables — re-resolving on re-send