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.
Opening Composer
Section titled “Opening Composer”The toolbar has a Proxy / Compose toggle in its left cluster. Click it to switch the main view from the live log to Composer. The toggle is sticky — Probe remembers which view you used last.
You can also jump in from a captured request: right-click any row in the log table and pick Replay in Composer. The method, URL, headers, and body get copied into a fresh draft request.
Layout
Section titled “Layout”┌──────────────┬───────────────────────────────────┐│ │ ┌─ Tabs ──────────────────────┐ ││ Collection │ │ GET /users POST /login │ ││ sidebar │ ├─────────────────────────────┤ ││ │ │ URL bar + Send button │ ││ ─ Folders │ │ Params │ Headers │ Body │ ││ ─ Requests │ │ Auth │ Scripts │ Tests │ ││ ─ Envs │ ├─────────────────────────────┤ ││ │ │ Response: status / time / │ ││ │ │ size + body / headers │ ││ │ └─────────────────────────────┘ │└──────────────┴───────────────────────────────────┘The collection sidebar on the left holds your saved requests, organised into collections and folders. The request editor in the center is where you build a single request. The response panel below it 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.
Building a request
Section titled “Building a request”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).
Below the URL bar is a row of sub-tabs:
- Params — query parameters as a key/value table. Toggling rows on and off updates the URL preview live.
- 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.
- Body — request body, with the type picker described below.
- Auth — request-level auth config; see Authentication.
- Cookies — per-request
name=valuecookies as a key/value table; see Cookies below. - Pre-request — a JS script that runs before the request goes out. Set variables, sign payloads, fetch tokens — same
proAPI as the global Scripting feature. - Tests — a JS script that runs after the response comes back, with assertions. Pass/fail results show in the Tests sub-tab of the response panel.
Body types
Section titled “Body types”Pick the body type from the content-type dropdown above the body editor. Probe supports seven shapes:
| Type | When to use | Editor |
| --------------------------------- | ------------------------------------------ | ------------------------------- |
| (empty) | GET, HEAD, or any request with no body | None — leave the body blank |
| application/json | Most REST APIs | JSON editor with pretty-print |
| application/graphql+json | GraphQL endpoints | GraphQL explorer: query + variables, introspection, autocomplete, docs tree |
| application/x-www-form-urlencoded | HTML form submissions, OAuth token endpoints | Key/value table |
| multipart/form-data | File uploads, mixed text + binary fields | Key/value table with file picker per row |
| text/plain / text/xml | SOAP, plain text payloads | Plain text editor |
| application/octet-stream | Raw binary upload from a file | File picker — body is read straight from disk |
The JSON and XML editors have a Beautify button that reformats the body in place.
Cookies
Section titled “Cookies”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.
Sending
Section titled “Sending”The Send button to the right of the URL bar fires the request through Probe's proxy core. The response panel below fills in with:
- Status code and reason phrase, colored by class (2xx green, 4xx orange, 5xx red).
- Elapsed time for the round-trip.
- Response size in bytes.
- Headers, Body, Cookies, and Tests sub-tabs.
The response body uses the same renderers as the live log's detail panel — JSON pretty-print with collapsible nodes, image preview for image responses, raw view for everything else.
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.
Every send 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.
Generating code
Section titled “Generating code”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 before the snippet is built, 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.
Saving requests
Section titled “Saving requests”A draft request lives in its tab until you save it. Hit Cmd+S (macOS) / Ctrl+S (Windows), 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.
Drafts persist between launches even when unsaved, so you can quit and pick up where you left off.