Send an HTTP request from a workflow

Last updated: September 1, 2026

The Send HTTP request action lets a workflow reach out to one of your organization's approved external systems over HTTP. Use it to push data out — notify your own system when something happens in Nash — or to pull a value back into the workflow so a later step can react to it.

Note

This is a beta feature. Reach out to Nash if you'd like early access.

Before you start: an HTTP connection

The action can only reach an approved external API, which Nash calls an HTTP connection. A connection is set up ahead of time by an organization admin, and a workflow author simply picks one from a list — you never type a URL or a credential into the workflow itself.

A connection pins three things:

  • Where the request can go — the secure (HTTPS) endpoint, meaning the base address and the paths a workflow is allowed to call.
  • How it authenticates — the credential lives inside the connection, encrypted. A workflow author never enters it, sees it, or can override it.
  • What the request may look like — which methods, headers, query parameters, and body fields an author is allowed to use.

Setting up connections is self-serve: an organization admin creates and manages them, no need to go through Nash. If you're building a workflow and don't see a connection to choose, that just means one hasn't been created yet — ask an organization admin to set up an HTTP connection.

Add the action to a workflow

In the workflow editor, add the Send HTTP request action, then fill in:

  1. Connection — pick the approved external system to call. Everything else you can set is bounded by what this connection allows.
  2. Method — choose the HTTP method (for example GET or POST), within the methods the connection permits.
  3. Path — the specific path to call, under the connection's allowed prefix (for example /orders/ plus an identifier).
  4. Query parameters, headers, and request body — optional, and each limited to the names the connection allows. Authentication headers come from the connection, so you don't set those here. A GET request sends no body.

The path, query parameters, headers, and body can all include workflow variables with the {{ ... }} syntax — for example {{ order.id }} — so the request carries live data about the order, delivery, or job the workflow is acting on. A few things to know about variables here:

  • A field set to exactly one {{ ... }} keeps the value's real type, so you can drop a whole object or a number into the body, not just text. When the {{ ... }} is part of a larger string, it's inserted as text.
  • Don't type secrets in directly. A header, query, or body value whose name looks like a credential — a token, API key, or password — is rejected if you paste a literal value. Use a {{ ... }} variable, or better, let the connection's authentication handle it.
  • A missing or unknown variable makes the step fail rather than quietly sending a blank, so reference only fields that exist for your trigger.

For the general mechanics of adding and wiring actions, see build a workflow in the portal.

Variables you can use

The path, query parameters, headers, and body can carry {{ variables }} with live data about the order, delivery, or job the workflow is acting on, plus results captured by earlier steps. For the full list of placeholders and how they resolve, see Workflow variables reference.

Use the response

You can bring one value out of the response back into the workflow. Point at a field in the returned JSON — for example the id in a response envelope — and Nash stores that single value in a variable a later step can use. If you don't pick a field, Nash stores the response's HTTP status code instead. Either way you choose how it's stored: as text, a number, or true/false.

The action also records whether the call succeeded, the status code it came back with, and how long it took. A later filter or branch can read those, so your workflow can react when a call fails — for instance, tag the job or send a notification if the request didn't go through.

You also choose what happens if the request fails: fail the workflow, which stops the run (the default), or continue, which lets the workflow go on so a later step can inspect the result and branch on it.

The full response body isn't kept. Only the one value you map, plus those success-and-status fields, are available to later steps.

Good to know

Keep these in mind as you design the request and whatever receives it:

  • Approved destinations only. The action reaches the secure external systems set up as connections — it can't call an arbitrary address.
  • It runs once, in the background. Nash sends the request a single time and doesn't automatically retry it, doesn't follow redirects, and doesn't guarantee the call arrives exactly once. Design the receiving system so it's fine with a request that's occasionally missed or repeated.
  • Duplicate-safe for changes. For methods that change data, the action can attach an idempotency key so a receiver that supports it can ignore an accidental duplicate — it's on by default.
  • It's quick by design. The request has a short timeout — a few seconds, up to 30 — so it suits fast calls, not long-running work.
  • Requests and responses are capped at roughly 1 MB each, so send and expect compact payloads.
  • Not available on the "Order is being created" trigger. That trigger runs while the order is still being set up, and this action runs in the background after the fact — so it isn't offered there. It's available on other triggers.

Availability

Any organization using Workflows has the Send HTTP request action — it isn't separately gated. What it needs is a connection to call, and that's created by an organization admin. Once at least one connection exists, anyone building a workflow can use it.

Related