Request a connection from a client

When a workflow needs a client's account (their Slack, their HubSpot, their Stripe), you do not collect their password or paste an API key on their behalf. You queue a request on each node that needs it, then send the client one email. They authorize each app through the provider's own consent screen, and the connection drops into the matching node automatically.

This page covers the agency side: queuing requests in the editor and dispatching them in a single batch. The client side is covered in Client authorizes an app.

When to use this

Use a client connection request whenever a node's connection should belong to the client instead of your agency. On the node's connection panel you set the source to Client provides the connection. The slot then reads:

The agency queues a request and the client connects {app} from their portal or via a magic-link email.

This flow is OAuth only. The client authorizes through the provider's consent screen, so it works for any app that connects over OAuth. It does not collect API keys, subdomains, or any other credential type from the client. If you need to connect your own agency account by API key, use Connect an account instead.

Queue a request on a node

Queuing creates the request but sends nothing. No email leaves your account at this step, and the request stays invisible to the client until you dispatch it. That is why the button reads Add to client request queue and not "Request from client."

1. Set the node's connection source to Client provides

   Open the node that needs the client's account, find its connection panel, and choose Client provides the connection. The credential picker is replaced by a slot with an Add to client request queue button.

2. Open the queue modal

   Click Add to client request queue. A modal opens titled Add {app} request to queue with the description: "Queue a connection request for this app. No email is sent until you send the queued requests to the client."

3. Choose the recipient

   In Recipient email, pick an existing workspace member or type any other client email. Members appear under a Workspace members group; a typed address appears under Other as Use "alice@client.com".

   The hint under the field tells you which channel the recipient will use and how long they have once you send:

   • A workspace member: "Will open inside the portal. They have 4 hours from dispatch to connect."
   • Any other email: "Will receive a magic-link email (no portal account required). They have 7 days from dispatch to connect."
4. Add an optional note

   Use Note to client (optional) to explain why you need the connection. The field caps at 256 characters, shown live as a counter. This note appears in the email and on the authorization page, so write it for the client, for example: "We use your Slack to post deal alerts to #sales."

5. Review the scopes and queue it

   Requested OAuth scopes lists the permissions this app's action requires. They are read only ("Scopes are derived from the action definition and not editable here"). Click Add to queue. You see the toast "Added to client request queue" and the node's slot now shows a status badge instead of the button.

Repeat this for every node that needs a client connection. Multiple nodes for the same recipient are bundled into one email when you send, so queue everything first.

Send the queued requests

Queued requests do not expire on their own. They wait until you send them or cancel them. There are two ways to send.

Send from the editor

Open the Client connection requests panel in the editor sidebar. It groups every queued and dispatched request for this workflow by recipient, and describes itself as: "Queued and dispatched-pending requests for this workflow, grouped by recipient. Use Send to client to mail every queued request, or Cancel queued requests to clear the slots."

Click Send to client. Every queued row for this workflow is dispatched, and exactly one email goes to each recipient covering all the apps in their bundle. You see the toast "Sent requests to client" with a description like Emailed 2 recipient(s) covering 5 request(s). The expiry clock (4 hours or 7 days) starts now, at dispatch, not when you queued the request.

Let publishing send them for you

You do not have to click Send to client. When you publish a workflow, any still-queued requests for that workflow are dispatched automatically, so the client receives the email at publish time. If you publish before sending manually, the email still goes out.

Verify it worked

After you send, check the per-node slot badge and the sidebar panel:

• Queued (not yet sent): the request exists but has not been emailed. If you still see this after sending, the send did not reach this row.
• Waiting on client: the email was sent and you are waiting for the client to authorize. Dispatched rows show an "Expires {date}" line and a Resend email button.
• Connected (or "Connected as alice@client.com"): the client authorized the app. The connection is now wired into the node, and the workflow can run.

When every client-provided node reads Connected, the workflow is no longer blocked on credentials.

Resend, cancel, or change a request

You can resend a dispatched request that the client has not acted on yet. In the sidebar, the dispatched row has a Resend email button. Resending mints a fresh link, so the old link stops working and the client always has at most one valid link. Resends are capped at 3 per request with at least 5 minutes between them. The button pre-disables and tells you why, with hints like 2 sends left., Available again in 4 min., or Resend limit reached (3 / 3).

To clear a request you no longer need:

• A single dispatched request: click the Cancel button on its row.
• Every queued request for the workflow: click Cancel queued requests. A dialog asks "Cancel 3 queued request(s)?" and warns "This clears the linked slots; you'll need to re-add each request before publishing." Confirm with Cancel requests or back out with Keep queued.

There is no way to edit a sent request's recipient or scopes. Cancel it and queue a new one.

Troubleshooting

The Resend email button is disabled. Resending is only allowed on a request that has been dispatched and is still waiting on the client. A queued (not yet sent) request cannot be resent; send it first. If the request is already dispatched, the button disables when you have hit the cap of 3 resends or are inside the 5-minute cooldown. The hint text tells you which.

The slot still says Queued (not yet sent) after publishing. Auto-dispatch only sends requests whose origin is the workflow you published. A request queued from a different workflow is not sent by that publish. Open the Client connection requests panel for the workflow that owns the request and click Send to client, or publish that workflow.

Add to queue does nothing or the request will not save. Each workspace can hold up to 1,000 pending requests. At that cap the create call is rejected. Cancel stale requests in the sidebar, or wait for clients to authorize the ones already sent, then try again.

Related

• Client authorizes an app: what the client sees and does after you send.
• Manage client connections: view connection health, refresh, or revoke after a client connects.
• Credential requests reference: every request status, link expiry, and resend rule.