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.

Params and headers are editable rows — tick a row to disable it without deleting it.

Params and headers are editable rows — tick a row to disable it without deleting it.

Request body

The Body tab supports several content types:

  • Raw — free-form text (JSON, XML, plain text). JSON can be beautified.
  • Form URL-encoded — application/x-www-form-urlencoded key/value pairs.
  • Multipart — multipart/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.
  • Preview, for HTML responses only — the body rendered as a page instead of as source. See HTML preview below.
  • 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.
The response pane tabs: pretty or raw Body, the response Headers, and the raw HTTP exchange.

The response pane tabs: pretty or raw Body, the response Headers, and the raw HTTP exchange.

HTML preview

When a response comes back as HTML (text/html, application/xhtml+xml), a Preview tab appears next to Body and renders it as a page — handy for reading a server’s error page, a redirect interstitial, or a templated email rather than squinting at its source. Copying from the Preview tab still copies the HTML source.

The preview is deliberately inert. Impostor renders it in a frame with every sandbox permission withheld and the app’s own content-security policy applied inside it, so a response body cannot run scripts, submit forms, navigate the app, or load any remote resource. Inline styles and data: images render, which is enough for the page to look like itself; remote images, stylesheets and fonts show as blocked. A response body is untrusted input, and previewing one never gives it a way to reach the network or the rest of the app.

Very large bodies (over 5 MB) aren’t previewed — read them on the Body tab.

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.

App-level defaults for timeout and redirects; a request or folder can override them.

App-level defaults for timeout and redirects; a request or folder can override them.

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.