Skip to content

Composer Overview

Composer is Probe's request builder. It works the way Postman or Insomnia does — you pick a method, type a URL, fill in headers, body, and auth, and hit Send. The difference is that Composer lives inside the proxy: every request you send still flows through the MITM core, so it lands in the log table next to the real traffic from your apps and devices.

That means anything you've set up for inspection — Domain Watch, breakpoints, Map Local, Throttle, Scripting — applies to Composer requests too. You can hit a flaky endpoint a hundred times under simulated 3G, edit a response in flight, or run a script against the result, all without leaving Probe.

Composer in API Client mode — collection sidebar on the left, request editor in the middle, response pane on the right

The sidebar has three icons at the top: Traffic, API Client and Files. Click API Client to switch the main view from the live log to Composer.

You can also jump in from a captured request: right-click any row in the log table and pick Compose. The method, URL, headers, and body get copied into a fresh draft request.

Diagram of the Composer. 1: each open request is a tab along the top (GET /users, POST /login). 2: the collection sidebar on the left lists collections, folders and requests under a Collections header with History, Manage Environments (globe), Import and New Collection buttons and a Search requests field, with Flows at the bottom. 3: the URL bar holds the method, the URL ({{baseUrl}}/users), the environment (Dev), the timeout (30s) and Send. 4: the request pane's tabs are Headers, Params, Body, Auth, Cookies, Raw, Notes, Pre-request and Tests. 5: the response pane, beside the request pane, shows Save to File (an icon), the status (200) and the time (142ms), with Headers, Body, Raw, Cookies and Test Results tabs.Diagram of the Composer. 1: each open request is a tab along the top (GET /users, POST /login). 2: the collection sidebar on the left lists collections, folders and requests under a Collections header with History, Manage Environments (globe), Import and New Collection buttons and a Search requests field, with Flows at the bottom. 3: the URL bar holds the method, the URL ({{baseUrl}}/users), the environment (Dev), the timeout (30s) and Send. 4: the request pane's tabs are Headers, Params, Body, Auth, Cookies, Raw, Notes, Pre-request and Tests. 5: the response pane, beside the request pane, shows Save to File (an icon), the status (200) and the time (142ms), with Headers, Body, Raw, Cookies and Test Results tabs.

The collection sidebar on the left holds your saved requests, organised into collections and folders. The URL bar across the top of the editor holds the method, the URL, the environment, the timeout and Send. Below it, the request pane on the left is where you build a single request, and the response pane beside it on the right fills in once you hit Send.

Each open request is its own tab along the top of the editor — browser-style. Switch between drafts without losing what you typed; close a tab and Probe asks if you want to save it first if there are unsaved edits.

The URL bar takes the full URL, including any {{variables}} you want to interpolate. The method dropdown to its left covers the seven common HTTP verbs (GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS). The timeout picker next to Send sets how long a send waits for the response, headers and body together (30 s by default). It's saved with the request, so a collection run and a Flow request node that references the request wait as long. A REST or MCP send waits at most 110 s whatever the saved value (a longer timeout is clamped), and it is stopped waiting for after 115 s in all, scripts included, so the caller gets an error result instead of a 504. A flow generated from a folder or collection keeps the copy of each request it was made with, timeout included.

The query string in the URL goes out exactly as you typed it, on a single send, in a collection run, on a REST or MCP send and in a Flow: a +, / or = and a repeated key aren't re-encoded. Most servers read a + in a query as a space, so type %2B for a literal plus. An enabled Params row whose key the URL doesn't have yet is added to the query, encoded; when the URL and a row share a key, the URL wins.

As you type, the URL bar suggests URLs you sent before, from History. A URL that History saved with a masked value is suggested the way you composed it, with its {{variables}}, or not at all.

Below the URL bar, the request pane has a row of sub-tabs:

  • Headers — request headers as a key/value table, with autocomplete for common header names. Authorization headers added by the Auth tab don't show up here; they're applied at send time.
  • Params — query parameters as a key/value table. Toggling rows on and off updates the URL preview live.
  • Body — request body, with the type picker described below.
  • Auth — request-level auth config; see Authentication.
  • Cookies — per-request name=value cookies as a key/value table; see Cookies below.
  • Raw — a read-only preview of the raw HTTP request, with variables resolved.
  • Notes — a free-text description of the request.
  • Pre-request — a JS script that runs before the request goes out. Set variables, sign payloads, fetch tokens — with the pro API in the Scripting API Reference (live-traffic script rules use handleRequest / handleResponse instead).
  • Tests — a JS script that runs after the response comes back, with assertions. Pass/fail results show in the Test Results sub-tab of the response pane.

Pick the body type from the content-type dropdown above the body editor. Probe supports seven shapes:

TypeWhen to useEditor
(empty)GET, HEAD, or any request with no bodyNone — leave the body blank
application/jsonMost REST APIsJSON editor with pretty-print
application/graphql+jsonGraphQL endpointsGraphQL explorer: query + variables, introspection, autocomplete, docs tree
application/x-www-form-urlencodedHTML form submissions, OAuth token endpointsKey/value table
multipart/form-dataFile uploads, mixed text + binary fieldsKey/value table with file picker per row
text/plain / text/xmlSOAP, plain text payloadsPlain text editor
application/octet-streamRaw binary upload from a fileFile picker — body is read straight from disk

The JSON and XML editors have a Beautify button that reformats the body in place.

Probe keeps an automatic cookie jar per collection: any Set-Cookie header in a response is captured and, on later sends, the matching cookies are attached to the outgoing Cookie: header automatically (domain-filtered). You don't have to do anything for that — it just works.

The Cookies sub-tab lets you set cookies explicitly on a single request. Add name=value rows the same way you would headers, and toggle rows on and off. These manual cookies are:

  • Always sent for this request — they're not domain-filtered like the jar.
  • Merged with the automatic jar into one Cookie: header at send time. A manual cookie overrides a jar cookie of the same name, so you can pin a specific value without clearing the jar.
  • {{variables}}-aware — both the name and value are resolved with your active environment before the header is built.

Manual cookies are saved with the request, so they survive closing the tab or relaunching Probe.

The Send button to the right of the URL bar fires the request through Probe's proxy core. The response pane on the right fills in with:

  • Status code, colored by class (2xx green, 3xx orange, 4xx and 5xx red). The reason phrase shows in the Raw sub-tab.
  • Elapsed time for the round-trip.
  • Save to File (the document icon), to write the response body to a file.
  • Headers, Body, Raw and Cookies sub-tabs, plus Test Results once a test script has run.

The response body is shown with JSON pretty-print and collapsible nodes, an image preview for image responses, and a raw view for everything else. (The image preview is Composer-only: the live log's detail panel doesn't capture image bodies.)

Because the request goes through the proxy, you'll also see it appear in the log table (when you switch back to Proxy view) — same row format as captured traffic, with a small badge marking it as a Composer request.

The last response for each request is saved to disk, so it's still there if you close the tab or quit and relaunch Probe — no need to resend just to see what came back last time. Only the most recent response per request is kept (up to 100 requests, oldest evicted first), and a very large body is truncated to 256 KB when saved; a restored response that was truncated shows a note above the body. Like History, the saved copy keeps no cookie values: each Set-Cookie value is replaced with •••••••• (cookie names and attributes stay), so a restored response shows them masked. The error text of a failed send, which repeats the URL it was sending, is saved with secret values and URL passwords masked the same way.

Every request you send from the editor, or through the REST API or MCP, is also logged to the History tab — an append-only record of the last 200 requests (and their responses), searchable and reloadable back into the editor, independent of the per-request "last response" above. The requests of a collection run aren't logged there; the run's results table lists them.

Every request has a Generate Code action (toolbar icon above the URL bar) that turns it into a ready-to-run snippet in another language: Python (requests), JavaScript (fetch), JavaScript (Axios), Dart (package:http), Go (net/http), Swift (URLSession), PHP (curl_*), and cURL. {{variables}} are resolved with your active environment and the globals before the snippet is built, except secret variables, which stay as {{name}} so a snippet never shows a secret. The snippet's URL is built the way a send builds it: the query as you typed it, plus each enabled Params row whose key the URL doesn't have (Python and Axios pass those rows as params). Headers/params respect their enabled toggle, and the cURL output uses the conventional multi-line, backslash-continued shape you'd get from a browser's "Copy as cURL". Pick a language from the row of buttons, then Copy Code to grab it.

A draft request lives in its tab until you save it. Hit Cmd+S (Ctrl+S on Windows), or click Save to Collection in the breadcrumb bar above the request, and Probe prompts you to pick a collection and an optional folder. Once saved, the request becomes a permanent entry in the sidebar tree — click it any time to reopen its editor with everything intact.

A draft lives in memory only: one you have not saved to a collection is gone when you quit Probe, so save it first. Saved requests are kept.

The Templates button in the bar under the request saves the request you are editing as a named template, and applies a saved one to the editor. Delete Template… removes one after you confirm its name. A template keeps the request only: never the response, and never a secret. The values of secret variables, credentials typed into the Auth tab, credential headers such as Authorization and cookie values are blanked when it is saved, while {{placeholders}} stay, so keep credentials in variables.