Noodle 0.8.0 let a request define what a useful response looks like. Version 0.8.1 lets that response become useful to the next request. A collection can now capture typed values from one response and resolve them through the same variable syntax already used by environments.

The terminal workspace also bends to the task. The sidebar and the boundary between request and response panes can be resized with the mouse without adding another settings screen or changing the keyboard workflow.

Capture once, use it next

A request declares a capture mapping beside its assertions:

name: Create User
method: POST
url: $base_url/users
body_type: json
body: |
  {"name":"Ada"}
capture:
  created_user_id:
    value: body.id
  request_id:
    value: headers.x-request-id

A later request in the same ordered collection run can use those names like ordinary environment variables:

name: Get Created User
method: GET
url: $base_url/users/$created_user_id
headers:
  X-Request-ID: $request_id

Capture expressions use the same response vocabulary as assertions: status, response time, case-insensitive headers, and JSON body paths. Values keep their type inside the run. Strings substitute verbatim, while numbers, booleans, null, arrays, and objects use their JSON representation at the request boundary.

Environment and secret values load first. Successful captures override names in that starting environment, and the latest successful capture wins. The scope belongs to one command, disappears when it returns, and never edits request YAML, environment files, settings, or timeline history.

A workspace that fits the request

Drag the divider after the sidebar to give long request names more room. Drag the request/response boundary vertically in stacked mode or horizontally in side-by-side mode. Each layout remembers its own split for the current session, and a double-click returns a divider to its default.

The minimum sizes adapt when the terminal narrows, then the preferred proportions return when more space is available. Resizing does not steal focus from the active pane, so mouse adjustments and keyboard navigation can stay in the same flow.

Failures without stale state

Captures are evaluated after a response arrives and before assertions. Every successful value commits even if another capture, the HTTP status, or a later assertion fails. A failed recapture leaves the prior successful value intact, the request is marked failed, and the rest of a collection run continues in collection order.

Human output reports capture counts without printing raw values. Structured output includes individual results for automation, with values matching known environment, proxy, or TLS secrets redacted. Response data can still be sensitive, so JSON run output should be handled like any other server payload.

See the collection format reference for capture syntax and expression rules, the Automation guide for chaining behavior, and the layout reference for mouse resizing.