Skip to content

Request workbench

The request workbench is where you build, save, and execute individual HTTP requests. Open API → Requests in the app sidebar. Requests are saved — not throwaway — so the call you debug today becomes the building block of a flow tomorrow.

Every request lives in a collection. Collections contain folders, so you can organize requests the way your API is organized — by resource, by service, by team. Collections are searchable, which matters once a spec import has generated dozens of requests.

You can populate a collection two ways:

  • Manually — create a request from scratch in the workbench. Use this for endpoints that are not in a spec: internal tools, temporary endpoints, third-party APIs.
  • From an OpenAPI spec — use Import OpenAPI to turn every operation in a spec into a saved request. See OpenAPI import & sync.

Both kinds of request behave identically once saved.

The workbench is multi-tab: open several saved requests side by side and switch between them while you work. Each tab is a saved request, so changes persist with the request rather than evaporating when you close the tab.

Each request has four configuration tabs:

  • Params — query parameters appended to the URL.
  • Headers — request headers, such as Content-Type or a signature header.
  • Auth — authentication helpers, including API-key placement options that control where the key is attached to the request.
  • Body — the request payload.

When you execute a request, Echopoint runs it server-side and returns the result to the workbench — your browser never calls the target API directly. The response panel shows the response body and response headers for each execution.

Reference variables anywhere in a request with double-brace syntax:

{{BASE_URL}}/payments

Variable values come from your environments — organization defaults with named overlays such as staging, plus flow-level variables when the request runs inside a flow.

A saved request is one call. To chain calls — extract a value from one response and feed it into the next, assert on status codes and fields, and run the whole sequence from CI — add the request logic to a flow with Request nodes. See Building flows and Outputs & assertions.