Connection blocks

What it is. A brokered OAuth integration. You declare the slot and its provider in the file; a human authorizes the grant once in the Portal; Swirls issues short-lived tokens at run time.

Use it when a workflow or channel talks to Slack, Linear, Discord, LinkedIn, or Microsoft and you do not want to create, store, or rotate API keys for it. This is the most secure option: there is no credential to leak.

Works with type: http nodes (via connection:), channels (a channel uses its bound connection to talk to its platform), and the project's Connections page in the Portal.

connection

Connections are project-scoped. You can declare as many of the same provider as you need (for example two separate Slack workspaces).

connection slack_sales {
  label: "Sales Slack"
  provider: slack
}

Reference it from an HTTP node with connection::

node post_update {
  type: http
  label: "Post to Slack"
  connection: slack_sales
  url: @ts { return "https://slack.com/api/chat.postMessage" }
}

A node sets either auth: (your own credentials) or connection: (a brokered grant), never both. channel blocks bind a connection: the same way, where the connection's provider must match the channel platform. Chat uses that connection to authenticate when it replies on the platform.

Because the file references the connection by name (no IDs to copy and no secrets to provision), an agent can author the whole workflow end to end; the only human step is the one-time authorization.

Authorize in the Portal

After deploying, open the project's Connections page to authorize an account and bind it to each declared slot. Renaming a connection means reconnecting it.

Further reading

• Auth blocks: for credentials you hold yourself
• Channels: binding connections to chat platforms