Request Panel
Below the method and path row, the endpoint editor is split into two columns. The left column — covered in this sub-section — is the Request Panel. It describes what the mock expects from the incoming request. The right column is the Response Panel, covered next. The two columns are always visible at the same time.
Three Sub-Tabs: Body, Params, Headers
The top of the request column has a thin row of three sub-tabs. Exactly one sub-tab is visible at a time; switching between them does not lose any data you have entered:
- •Body: one or more request body variants, each with its own content type. See Body Variants below.
- •Params: a key-value editor for the query string. Rows here and the query string portion of the path field stay in sync; editing one updates the other.
- •Headers: a key-value editor for request headers, plus an auto-generated Content-Type row that follows the chosen body type. See Headers (Auto & Custom) for the full story.
Body Variants
The Body sub-tab opens with its own thin tab bar on top, and that bar is where request body variants live. A variant is a specific request body written in a specific content type. Most endpoints only need one variant, but nothing prevents you from having several — useful when you want to document that the endpoint accepts both application/json and application/xml, for example.
- •Add a variant: the + button at the end of the variant tab bar opens a dropdown of body types that have not been added yet — the same type cannot be used twice for the same endpoint.
- •Switch body type on an existing variant: the Body type dropdown in the variant's header lets you change the content type of the first variant at any time. Variants added afterwards have a fixed type (to keep the set of types consistent with the variant tabs).
- •Delete a variant: the small X on each tab removes that variant. When only one variant remains, the X disappears.
Body Types and Editors
The editor used for the body depends on the chosen content type:
- •None: the content area is blank and shows the message "This request does not have a body". Use this for endpoints like a plain GET that never carry a body.
- •JSON, XML, Text: a CodeMirror editor with syntax highlighting for the chosen language. JSON and XML additionally get live validation; if the body is not parseable, a thin amber banner appears at the bottom with the parse error. JSON and XML also get Format and Minify buttons in the hover toolbar.
- •Form Data, URL-Encoded: a key-value table instead of a code editor. Each row has an enable checkbox, a key, a value, and a delete button. These are stored internally as JSON and rendered as rows.
- •Binary: not supported by the mock server. If you import an HTTP request that uses a binary body, it is automatically downgraded to None inside the mock editor.
Hovering the CodeMirror editor reveals a small toolbar in the top-right corner with a Copy button — and, for JSON/XML, Format and Minify buttons.
Match Body
Above the body editor there is a small Match Bodycheckbox (hidden when the content type is None). Turning it on marks this variant's body as part of the incoming-request contract — a signal that the mock should pay attention to the body shape when deciding whether this endpoint is the right one. For the finer-grained case of picking one response out of several based on what is inside the incoming body, use the Rules tab on the response side instead; see Rules — Conditional Responses.
Params & Headers Sub-Tabs
The Params sub-tab is a plain key-value editor for query parameters — one row per parameter with an enable checkbox, a key, a value, and a delete button. Any changes here are reflected back into the query string portion of the path field above.
The Headers sub-tab shows the same auto-generated Content-Type row and custom header table that the Response panel uses, plus one extra checkbox — Match Headers — that lives only on the request side. See Headers (Auto & Custom) for the shared details.