REST Request Step

Description

The REST Request step calls a REST API as one step in a workflow. It’s a single, Postman-style step for the whole “build → send → inspect” loop: pick an endpoint (typed in by hand or imported from a Postman collection, an OpenAPI/Swagger spec, or a HAR capture), set headers, query parameters, and a body, fire a test request to see the live response, then save the step.

You choose where the response goes. By default it’s parsed into a table. Alternatively, the step can capture the response into workflow variables so a later step can branch on the status code or read a value out of the body.

Note

The REST Request step replaces the older REST-flavored steps with one unified step. Use it for new work; existing REST steps keep running.

Before You Start

You’ll usually want a connection of the REST kind, which holds the base URL and authentication for the service. The step can also call a fully-qualified URL directly without a connection. See REST connections.

Add a REST Request Step

1. Open the workflow and add a step where you want it.
2. Choose REST Request (unified) as the step type (under the REST steps). The editor opens with a Request tab and a Response tab.

Build the Request

In the Request tab:

Endpoint Source

Pick how you’ll supply the endpoint, then PlaidCloud fills in the request for you:

• Manual — type the method and URL yourself.
• Postman collection (file) / Postman collection (URL) — import from a Postman collection.
• OpenAPI / Swagger (URL) / OpenAPI / Swagger (file) — import from an API spec.
• HAR archive (file) — import a request captured from your browser’s network log.

For an imported source, choose Load Catalog to list the available endpoints, filter to the one you want, and the step prefills the method, URL, headers, and parameters.

Connection, Method, and Endpoint

• Connection — the REST connection to authenticate with. Leave it unset to call a fully-qualified URL directly.
• Method — GET, POST, PUT, PATCH, DELETE, or HEAD.
• Endpoint — the path (when a connection is set) or a full URL.

Headers, Query Parameters, and Body

• Headers and Query Parameters are editable tables of name/value rows, each with an On toggle and a description. Add rows with Add and remove them with Remove.
• Body holds the request payload (JSON, form, or raw).

Variable Substitution

Anywhere in the endpoint, headers, query values, or body you can inject a variable at run time by wrapping its name in double braces: {{name}}. You can also write {{var.name}} for a workflow-run variable or {{project_var.name}} for a project variable — the prefix is optional and both resolve the same name.

Only double braces are substituted, so a single { or } in a JSON body is left exactly as written — you can freely mix variables into JSON, for example {"id": "{{var.order_id}}", "qty": 1}. An unknown variable name fails the step so a typo surfaces immediately.

When the workflow is started by a sensor or webhook, four trigger variables are also available: {{trigger_sensor_id}}, {{trigger_sensor_type}}, {{trigger_fired_at}}, and {{trigger_payload_json}} (the inbound payload as a JSON string — parse it in a later step to reach nested fields). On a manual or scheduled run these resolve to an empty string.

Test the Request

• Send Test Request fires the request with your current settings and shows the live response inline, so you can confirm the call works before saving.
• Copy as curl copies an equivalent curl command to the clipboard for sharing or debugging (with secrets masked).

Route the Response

In the Response tab, set the Response Destination:

Table (default)

The response is parsed into the step’s target table. The Pagination & Parsing group controls how:

• Row format and Items path — where the rows live inside the response.
• Pagination mode, Mode params, and Mode paths — how to follow multiple pages of results.
• Dump raw JSON instead of parsing rows — store the raw payload rather than parsing it into columns.
• Retries and Timeout (s) — how the request behaves under failure and how long it may run (timeout capped at 600 s). Retries apply only to idempotent methods (GET, HEAD, OPTIONS, DELETE); a POST, PUT, or PATCH is always sent once so a non-idempotent request body is never re-sent.

Workflow variables

Set Destination to Workflow variables and give a Variable prefix (a plain name such as my_call). The step fires one request and writes four workflow variables:

Variable	Contents
{prefix}_status	HTTP status code (for example, 200).
{prefix}_body	Response body as a string (JSON responses are stored as JSON text).
{prefix}_headers	Response headers as JSON text.
{prefix}_elapsed_ms	How long the request took, in milliseconds.

Reference them downstream like any workflow variable — for example {my_call_status}. This is the building block for “fire one request, then branch on the result” patterns.

Caution

The prefix must start with a letter or underscore and contain only letters, digits, and underscores. It can’t be one of the reserved names cloud, project, model, or date. In variable mode the step captures a single response — pagination and row parsing don’t apply.

Run the Step

The REST Request step runs like any other — as part of a full run or on its own (see Running one step in a workflow). In table mode it writes the parsed (or raw) response to the target table; in variable mode it sets the four variables for later steps to read.

Next Steps

• REST Request step reference — concise field list
• Manage workflow variables — read and set variables across steps
• REST connections — set up authenticated API connections