Set up an HTTP connection

Last updated: September 1, 2026

An HTTP connection is the approved external system a workflow's Send HTTP request action can call. Each connection pins three things: where requests may go, how they authenticate, and what shape a request is allowed to take. A workflow author never types a URL or a credential into a workflow — they pick a connection you set up, and the connection bounds everything they can do with it.

Note

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

Only organization admins can create and manage connections. Anyone who can build workflows can select a connection, but setting one up — its destination, credential, and allowed request shape — is an admin job. This article is for that admin.

Where to find it

Connections are managed from inside the Send HTTP request workflow action — there's no separate settings page for them. To open the manager:

  1. Open an existing workflow, or start a new one, in the workflow editor.
  2. Add or open a Send HTTP request action.
  3. Below the Connection dropdown, select Manage connections (the gear icon).

The Manage connections control appears only if you can manage the organization. If you build workflows but aren't an admin, you'll see the connection list but not this control.

The manager opens to a list of your organization's connections, each showing its name, whether it's active, its destination, and a summary of the methods and authentication it uses. From here you create a new connection or manage an existing one.

Create a connection

Choose New connection and fill in the form:

  • Name — a label you'll recognize the connection by in the workflow editor, for example "Order events API."
  • HTTPS base URL — the secure origin the connection is allowed to call: the scheme and host only, such as https://api.example.com. Enter just the origin; the endpoint path goes in the allowed path prefix below. Nash only allows secure (HTTPS) destinations on the public internet.
  • Allowed methods — which HTTP methods a workflow may use with this connection (GET, POST, PUT, PATCH, DELETE). Select at least one; POST is selected by default.
  • Allowed path prefix — the path under the base URL that workflows may call, for example /webhooks. A workflow can call this path or any path below it, and nothing else. Matching is by path segment: a prefix of /orders allows /orders and anything below it like /orders/123, but not a different segment like /orders-admin. Defaults to /.
  • Allowed workflow header names, Allowed query parameter names, and Allowed top-level JSON body keys — optional allow-lists that bound what a workflow author may put in the request. Enter comma-separated names. Leave a field blank to allow none of that kind — for example, leaving the header list blank means workflows can't add request headers through this connection.
  • Authentication — how Nash authenticates the request: None, Bearer token, API key header (a header you name, such as X-API-Key), or Basic authentication (a username plus a secret). Choosing anything other than None reveals the fields that scheme needs, including the Secret.
  • Secret — the credential value for the chosen scheme (see below). Required when authentication isn't None.
  • Default timeout (seconds) — how long a request may run before it's given up on, between 1 and 30 seconds. Defaults to 10. A workflow author can set a per-step timeout on the action, but this is the value their request uses otherwise.

Choose Create connection to save. A new connection is active right away.

The secret is write-only

You enter the secret once. Nash encrypts it and never shows it again — not to you, not to workflow authors, not through any API. After saving, the connection shows only the last few characters, so you can confirm which secret is stored without exposing it.

When you edit a connection later, the Secret field starts blank. Leave it blank to keep the current secret. To replace it, either type a new value or use Rotate secret.

Manage connections

Each connection in the list offers:

  • Edit — change any field. The form comes pre-filled, except the secret, which stays blank so you don't overwrite it by accident.
  • Rotate secret — replace the stored credential with a new one. Available on connections that use authentication. Use this when a credential is compromised or on a routine rotation schedule.
  • Activate / Deactivate — turn a connection on or off. A deactivated connection stays in the list but workflow authors can't select it, so you can take a destination out of service without deleting it.
  • Delete — remove a connection permanently. This is a two-step confirm. Warning: any workflow that still references a deleted connection will fail validation until someone picks a different connection for it, so re-point those workflows first.

There's no test or validate button. A connection is checked when a workflow that uses it actually runs — the request has to fall within everything the connection permits, or the step fails.

What a connection controls

A connection is a narrow lane you approve once. Everything you pin — the base URL, the allowed methods, the allowed path prefix, and the allowed header, query, and body-key names — is a boundary a workflow author can't cross. They can build a request that moves within that lane, but they can't widen it: they can't call a different host, use a method you didn't allow, reach a path outside the prefix, or set a header, query parameter, or body key you didn't list.

That's the point of connections. You approve the surface — where data can go, how it's authenticated, and exactly which fields may be populated — and workflow authors build within it. To let a workflow do something a connection doesn't allow, an admin edits the connection.

Related