How a connection is referenced
AcustomApi node carries connectionName: "...". The engine resolves that name against the workflow’s connections map at runtime — bringing in the right credentials and base configuration without ever embedding them in the workflow definition.
Common connections in production workflows:
Storage and scoping
Connections live outside the workflow definition — they’re managed at the tenant level so:- Multiple workflows share the same connection without duplicating credentials.
- Rotation in one place propagates everywhere.
- Audit logs reference the
connection_idrather than embedding the secret.
Rotation
1
Open the connection
Settings → Connections → click the connection.
2
Stage new credentials
Paste the new key/cert. Old credentials remain active.
3
Test
Run the built-in synthetic round-trip against a known-safe endpoint.
4
Promote
Switch the connection’s primary credential to the new one. New calls hit it immediately; in-flight calls drain on the old one.
5
Revoke
After the drain window, revoke the old credential upstream.
What’s available at templating time
When a node executes against a connection, the templating layer can reference the named secrets registered to that connection. The exact list depends on what the connection ships — for an HTTP-based connection it’s typically an API token, a signing key, and any provider-specific headers. The templating layer does not expose the connection’s base URL or its full credential bag. Custom API nodes still declare their full URL inendpoint; the connection’s base config (mTLS cert, timeouts, retry policy) is applied transparently.