Collections

A collection is a tree of saved requests. It’s the top-level container in the Composer sidebar — every saved request lives inside one. A collection holds folders, requests, environments, and a default auth/header config that descendants inherit.

Collections live on disk under ~/.probe/compose/ (one JSON file per collection). They’re plain text — committable to git, diffable, syncable through any file-sharing tool you trust.

The sidebar tree

The leftmost column in Composer is the collection sidebar. The header has a + button to create a new collection; right-click the header for import options (cURL or Postman).

Inside a collection, the tree mixes folders and requests:

▼ My API
  ▼ auth
    ▶ POST /login
    ▶ POST /refresh
  ▼ users
    ▶ GET /users
    ▶ POST /users
    ▶ DELETE /users/:id
  ▶ GET /health

Folders nest up to four levels deep. Each folder shows its total request count (including nested subfolders) as a small badge.

Creating, renaming, deleting

Right-click any collection, folder, or request to get its context menu:

Action	Where it shows up	What it does
Rename	Collection / folder / request	Inline rename — type, hit Enter
Delete	Collection / folder / request	Asks for confirmation, then removes from disk
New Request	Collection / folder	Adds an empty request as a child
New Folder	Collection / folder (depth < 4)	Adds a sub-folder
Move Up / Down	Folder / request	Reorders the item among its siblings
Run	Collection / folder	Opens the runner dialog — see below

To move an item between folders or collections, right-click and pick Move to…, then choose a target from the destination tree.

Inherited defaults

A collection (and any folder) can hold defaults that descendants pick up automatically:

• Default headers — a list of header rows that get added to every request in the collection unless the request already sets that header.
• Default auth — an auth config (Bearer, Basic, API Key, OAuth 2.0) that requests inherit when their own auth is set to Inherit from parent.
• Pre-request script and Tests script — JS that runs before/after every request in the collection, in addition to the request’s own scripts.

You configure these from the collection’s Info view: click the collection name in the sidebar header, or right-click → Collection Info.

How auth resolution works

When a request is sent, Probe resolves its auth like this:

1. If the request has an explicit auth config (anything other than Inherit from parent), that config is applied as-is.
2. Otherwise, Probe looks at the request’s collection. If the collection has a default auth, that’s applied.
3. If neither the request nor the collection sets auth, the request goes out without an Authorization header.

The same rule applies to headers: a header set on the request always wins over a default header on the collection. Defaults fill in the gaps; they never override.

Note

The current implementation walks request → collection. Folder-level auth defaults are stored on the model but aren’t yet consulted during send — set inheritable auth at the collection level for now.

Running a folder

Right-click a folder or collection and pick Run to fire every request inside it as a sequence. The runner dialog lets you:

• Pick a target — the whole collection or a specific folder.
• Set a delay between requests (helpful for rate-limited APIs).
• Set the number of iterations — repeat the whole sequence N times.
• Choose an environment for the run (overrides the collection’s currently active one).

Hit Run and Probe steps through each request, showing live status:

✓ POST /login          200    142 ms
✓ GET  /users          200     38 ms
✗ POST /users          400    104 ms   ← test failed
✓ DELETE /users/42     204     27 ms

The runner respects the order in the tree (top-to-bottom, depth-first). Each request’s pre-request and tests scripts run as normal — including any pro.environment.set('token', ...) calls, so a login response can populate the token used by the next request in the run.

After the run finishes, the results pane shows pass/fail counts, total elapsed time, and per-request response status, time, and assertion outcomes. Click any row to open that request’s response in the editor, just like a single send.

Persistence and sharing

Each collection serializes to one file at ~/.probe/compose/<collection-id>.json. The format is human-readable JSON — environments, variables, scripts, and all. To share a collection with a teammate, hand them the file (or check it into your repo). To export it in a format other tools understand, use Export as Postman from the collection’s right-click menu — see Importing for the round-trip details.

Related

Composer Overview The big picture — what Composer is and how it fits into Probe.

Environments & Variables Variables that swap between dev / staging / prod, scoped to a collection.

Authentication Configure auth at the request or collection level.

Importing (cURL & Postman) Pull a collection in from a Postman export, or paste a curl command.