Managing connections

Everything lives in Settings → connectors: click a connected provider to open its panel.

When a connection expires

OAuth grants can lapse (revoked on the provider side, expired refresh). The connection flips to reconnect needed (an amber badge in Settings and on any step picker using it) with a reconnect button that re-runs the OAuth dance into the same connection. Nothing needs rewiring: every step bound to it works again the moment reconnect finishes.

That's also the rotation story for API keys: reconnecting replaces the secret in place.

Connection settings

Some providers keep a setting or two on the connection itself, like Slack's Default channel or a self-hosted host for Gitea. The connect form asks for them, and each connection card has a Settings editor to change them later. A default channel is filled into any Slack step the AI wires to that connection without naming a channel of its own. Set it once; every future build inherits it.

Disconnecting

disconnect first tells you what it will touch: which workflows use the connection and how many of them are live. On confirm, every step bound to it loses its connection (the step turns red and the Inspector asks for one), and every live workflow that used it is turned off so its triggers stop firing. Nothing is silently rewired. Reconnecting the provider creates a new connection; when it is the only one for that provider, the AI's post-connect wiring binds the waiting steps to it, and you turn the workflow back on.

A sweep applies the same treatment to any step still bound to a connection that no longer exists, so a stale binding never keeps failing quietly: the step turns red and its live workflow is turned off until you pick a connection. It runs for your workspace right after any disconnect, and once a day as a backstop.

Named secrets for any step

Not every credential is an Authorization header. A token that goes in a URL, a key an agent prompt needs, a value a code step reads. These live in the Secrets connector: one connection holding any number of named, encrypted entries.

Create it once (Settings → connectors → Secrets → Create), then add entries: a name (STRIPE_KEY; letters, digits, underscores), the value, and an optional description. In any step's config write {{ secrets.STRIPE_KEY }} where the value belongs: a header value, a URL, a request body, a prompt, a code step string, an integration argument.

What happens at run time:

• The value is filled in only while that step runs, loaded through the execution's workspace scope.
• It is scrubbed from the step's output, logs and error before anything is stored or shown; «secret STRIPE_KEY» stands in.
• A reference to a name the workspace doesn't hold fails the step with the missing names spelled out, rather than sending an empty string.
• Entering the same name again rotates the value in place; every step referencing it picks up the new value on its next run.

The AI can do the same from chat: hand it a key and it stores it as a named secret and writes the reference, never the value. Over MCP, list_connections shows entry names and descriptions, never values.

Security notes

• Credentials are encrypted at rest and never rendered back into any UI, not to you and not to the AI.
• At run time, a step's connection is loaded through the workspace scope of the execution, so a binding that points outside your workspace simply doesn't resolve. Cross-tenant use is structurally impossible, not just forbidden.