Credentials

Credentials are how workflows authenticate against third-party services. You connect a service once; every node that supports that service can then use the connection.

Two kinds

• API key — paste a key from the provider (e.g. an Anthropic or SendGrid API key). Available immediately, no server-side configuration needed.
• OAuth — click through the provider’s consent screen (Google, Slack, Discord, …). On Cloud the common providers are already registered, so this is the consent screen and nothing else; self-hosting, the operator has to configure an OAuth app for that provider first.

Each node declares which credential types it supports; the editor’s credential picker only offers compatible connections. The credentials overview explains ownership and the UI key format used in API and MCP calls; the catalog lists every supported credential with its fields and the nodes that use it.

The security model

Credentials are treated as write-only secrets:

• Encrypted at rest with AES-256-GCM. The database never stores plaintext secret material.
• Never returned by read APIs. Once saved, secret fields come back masked — the UI shows that a value exists, not what it is. Updating a credential only overwrites the fields you actually change.
• Only decrypted at execution time. Workflows store a reference to a credential, never its contents — exporting or inspecting a flow can’t leak a secret. The runtime resolves the reference and decrypts just-in-time for the node execution.
• OAuth tokens auto-refresh. Expiring tokens are refreshed ahead of use; concurrent executions share a single refresh instead of racing.

Who can use them

A credential belongs to the organization it was created in, not to the person who created it — so a flow keeps running when its author is away, and every member can use a connection without ever seeing its contents. Nothing crosses the organization boundary: a credential ID from another organization simply resolves to not-found. See Organizations & members.