Credential Management
Named ActionFlows organization connections, runtime secret resolution, permissions, and current public-history redaction behavior.
Credential management
A credential in ActionFlows is an organization-owned connection resource. Depending on the integration, it can represent an OAuth install, an API key, a database connection URI, SMTP, S3, FTP, or an MCP connection. Flow nodes, triggers, and Agent capabilities that use catalog integrations reference the organization resource; they do not put a plaintext secret in the saved graph. Named HTTP tools are separate Agent tool records: their authentication payload is encrypted on the tool record, while static headers are stored in headersJson; they are not generic organization credential references.
There is no standalone Credentials screen, Test Connection control, or Share with Workspace control. Manage organization connections in the app.
Where connections live
Open Organization → Integrations.
| Integrations tab | What it stores |
|---|---|
| Integrations | OAuth and API-key connections for third-party applications |
| AI Vendors | Provider credentials used by AI services and models |
| Databases | Named PostgreSQL, MySQL, and MongoDB connection URIs |
| FTP | Named FTP connections |
| SMTP | Named SMTP connections for email and HITL SMTP |
| S3 | Named S3 connections |
| MCP Servers | Organization MCP connections, including URL, headers, or OAuth authentication |
A node inspector can also open the add-connection flow when the selected catalog integration needs a connection. OAuth redirect URLs and scopes come from the integration catalog row. Do not register a generic callback URL as a replacement for the catalog's OAuth configuration.
The public API does not create, return, or update organization secrets. Create connections in the app, then reference the saved resource from the product surface that needs it.
Named connection references
For API-key and connection-URI integrations, the current node snapshot can store a selectedIntegrationCredentialId and a display name. At runtime, the selected ID is matched inside the organization-owned credential list for the node's integration slug. Integrations that support multiple named connections can require an explicit selection; when a selection is absent, the resolver can use a single matching connection or the first match only for integrations that do not require explicit selection.
OAuth execution resolves an organization OAuth connection for the integration and retrieves the access token on the server. Do not copy the access or refresh token into a node input, Agent prompt, tool argument, or client configuration.
The current validator also recognizes a few legacy credential-shaped form fields. Those fields are not a substitute for the organization connection path used by current execution. Use the named connection UI and keep the graph free of inline secrets. validateFlow checks that the relevant credential or OAuth record is present, resolvable, and associated with an enabled integration; it does not verify secret contents or contact the provider.
What happens during a run
- The Flow node, trigger, or Agent capability identifies whether it uses an organization connection or a named HTTP tool record.
- For an organization connection, the runtime loads resources scoped to the owning organization.
- For an organization connection, it decrypts the selected credential or retrieves its OAuth token on the server. For a named HTTP tool, it reads the Agent tool record, decrypts its authentication payload, and uses its static headers; it does not resolve a generic organization credential for that tool.
- The node or tool function receives the material needed for that call.
- The result is recorded according to the node or tool output and the run-history redaction rules.
Secrets are not returned as public organization metadata. Public API, SDK, and hosted MCP responses expose only non-secret identifiers or state where applicable, not the encrypted secret or plaintext credential.
Redaction and run history
The public run-history read path uses a top-level field allowlist and removes recognized sensitive result keys such as apiKey, authorization, clientSecret, password, token, secret, and signing or encryption keys. This protects common credential fields, but it is key-based redaction—not a proof that every custom result field is free of personal, business, or provider-sensitive data.
A node can return a custom key that is not in the sensitive-key list. Do not rely on redaction as the only control for secrets. Keep secrets out of prompts, inputs, outputs, URLs, logs, and error details whenever possible, and review the actual data returned by a node before saving or sharing it.
Flow Requirements
In Actionflow Studio, Flow Requirements appears when a canvas-connected node is missing a required provider or integration connection. It lists the missing organization resource and opens the add-connection flow. It is a credential-presence/readiness surface, not a full validateFlow result and not a provider health check.
The server-side validator can additionally reject a reachable node when its catalog integration is disabled, a credential or OAuth record is not present/resolvable, an AI model is not selected, or a required input is empty. It does not prove that the stored secret works with the provider. See ActionFlow requirements.
Permissions
Organization permissions apply to credential resources:
- Owner and Admin: create, read, update, and delete credentials.
- Member: create and read credentials.
The custom-resource matrix is organization-scoped. Permission in one organization does not grant access to another organization's connections. Read the full Organization permissions matrix before sharing an API key or integrating a service.
Figma limitation
A Figma organization connection can exist while no draggable seeded Flow node is currently available. Figma is present in the integration catalog, but the Figma node is not currently selectable in the Flow node catalog. Do not plan a Flow around a Figma node until a seeded catalog row is available.
Inbound webhooks are not organization credentials
A flow webhook authenticates with a secret token in its generated path. That token belongs to the flow's Webhooks setting, not the Organization → Integrations screen. Channel trigger secrets and Action Agent binding secrets have separate lifecycles; do not reuse them as Flow credentials.