Saving and tabs

This page explains the per-request save state you see in the request area's name bar: when a request is "saved", "modified", or "unsaved", and what happens when the server's copy changes underneath you.

Request name bar

The thin row just above the URL bar shows:

• A small file-code icon
• The request's name (editable inline)
• A small dot when the request has unsaved changes
• The current save status on the right (saved, modified, saving…, save failed, save conflict, or unsaved request for a brand-new draft that has never been saved)

The name is editable. Press Enter or click away to commit; the new name is part of the next save, not a separate action.

Save states

Status	Meaning
unsaved request	The current draft has never been saved. Saving it creates a new request.
saved	The in-memory draft matches the last server-saved version.
modified	The in-memory draft has changes that have not been saved yet.
saving…	A save is in flight.
save failed	The last save request returned an error. The error is shown in the response panel.
save conflict	The server's copy is newer than the one you opened; the save was rejected. See below.

The Ctrl+S / Cmd+S shortcut triggers a save from any state.

What "save" actually does

When you save a request that has a server ID:

1. The frontend sends the full draft plus the revision number it originally opened.
2. The server compares that revision against the stored revision.
3. If they match, the server applies the update, increments the revision, and returns the new state.
4. If they don't match, the server returns a 409 with the current state.

When you save a request that has no server ID (the unsaved request case):

1. The frontend sends the full draft with no requestId.
2. The server creates a new request inside the currently selected collection. The collection is determined by the active context (the request area's currently selected tab and its collectionId).

If no collection is selected, the server creates one named New collection. The underlying routes are in API surface → Requests. The version-tracking term is defined in the Glossary → Revision.

Save conflicts

A conflict happens when the server's revision is newer than the one you opened. Typical causes:

• You opened the same request in two tabs and saved one of them.
• A CLI runner or another tool saved the same request.

The save conflict dialog offers three choices:

• Keep editing — leave your changes in the tab. The next save attempt will also conflict, but you can keep iterating.
• Save as new — save your draft as a brand-new request. The original is left alone. The new request is named <original> (copy N) if a copy with that name already exists, with N incremented.
• Reload stored — throw your changes away and load the latest server state into the tab.

Persistent conflicts after a CLI save usually point to a stale rewind_session cookie — see Local session is not initialized.

Closing a dirty tab

Closing a tab whose status is modified opens a confirmation dialog: "Discard unsaved changes?". You can either Keep open to return to the tab, or Discard to close it and throw the changes away.

Tabs in any other state close without confirmation.

Unsaved-changes guard

If you try to close the browser tab or refresh the page while at least one open request has unsaved changes, the browser shows the standard "Leave site?" prompt. This is the browser's built-in beforeunload dialog and it is only triggered when there's actually something to lose.

What's next?

• Collections and folders — where saved requests live
• Running a collection — sending every saved request in order
• Troubleshooting — common save error patterns