HTTP requests

Methods, query params, headers, request bodies, and reading the response.

The request editor is where you build and send HTTP requests. Each request is saved as a single YAML file in your workspace.

Method and URL

Pick the method — GET, POST, PUT, PATCH, DELETE, HEAD, or OPTIONS — and enter the URL. URLs (and almost every other field) support {{variable}} substitution, so you can write {{baseUrl}}/users/{{userId}} and resolve it per environment.

Press L to jump focus to the URL bar, and ⌘/Ctrl + Enter to send.

Query parameters and headers

The Params and Headers tabs are key/value editors. Rows can be toggled on and off individually, so you can keep optional parameters around without deleting them. Query parameters stay in sync with the URL.

Request body

The Body tab supports several content types:

  • Raw — free-form text (JSON, XML, plain text). JSON can be beautified.
  • Form URL-encodedapplication/x-www-form-urlencoded key/value pairs.
  • Multipartmultipart/form-data with a mix of text fields and file parts.
  • Binary — a single file sent as the raw request body. The Content-Type is auto-detected from the file extension (override it if you need to), and the file path supports {{variable}} substitution.
  • GraphQL — a dedicated query editor with a separate JSON variables pane. Both support {{variable}} substitution; the variables pane can be beautified and flags invalid JSON. On send it POSTs an application/json body of { "query": …, "variables": … } (variables are omitted when blank).

Reading the response

The response pane shows:

  • Status, time, and size at a glance, with colour-coded status.
  • Body, pretty-printed for JSON and rendered safely for other types. Binary responses are detected (and base64-decoded under the hood) and can be saved to a file.
  • Headers returned by the server.
  • Redirects, when any were followed — a ↳ N redirects chip next to the status expands to the full chain, one line per hop showing the status, the URL that answered it, and where it pointed.

Redirects

Redirects are followed by default, up to a hop limit (10 unless you change it). Both are settings on the request’s Settings tab, and both inherit: a request falls back to its nearest ancestor folder, a folder to its ancestors, and finally to your app-level defaults in Settings ▸ Request defaults.

Setting Max redirects to 0 follows none — the same outcome as turning following off. When a chain exceeds the limit, the request fails with an error listing the hops it did follow, so you can see where it looped before deciding whether to raise the limit.

History and re-running

Every send is recorded to an append-only history log in the workspace’s local-only .impostor/ directory (not committed to git). Open the History section in the sidebar to load a past request back into the editor and re-run it. Recording can be paused, and history cleared, from the section’s menu.

Tabs

The editor is tabbed — open multiple requests at once, each with its own state and a dirty indicator when unsaved. A blank + tab acts as a scratchpad. Close a tab with W.