Credentials
Per-user encrypted credentials - what gets stored, how it's encrypted, and which nodes need one.
Most action nodes need a secret to call a third-party API: an API key, a bot token, a connection string. Pipory stores these as credentials - named, typed, per-user records that nodes reference by id rather than embedding the secret in the workflow itself.
How storage works
Every credential has a name, a type (one of Pipory's 200+ CredentialType values - one per integration, for example ANTHROPIC, SLACK_BOT, POSTGRES, HUBSPOT), and a value. The value is encrypted at rest with Cryptr using a server-side ENCRYPTION_KEY - it is never stored or logged in plaintext, and is only decrypted in memory at the moment a node executes.
Credentials belong to the user who created them, not the workflow - add a credential once (from the Credentials page or from a node's dialog) and reuse it across every workflow and every node that needs that type.
Attaching a credential to a node
Open a node's dialog and pick (or create) the matching credential from a dropdown. The node stores only the credential's id in its config - exporting a workflow to JSON strips the id and replaces it with a placeholder naming the required credential type, so a shared or version-controlled export never leaks a secret. See Import/export.
Which nodes need a credential
It varies by node - check the Credential column in the node reference for any specific node. A few patterns worth knowing:
- No credential at all - the basic Slack and Discord nodes post through an incoming webhook URL pasted directly into the node's config (not a stored credential), and a handful of app nodes (Microsoft Teams, Mattermost, RSS) work the same way. The Slack API node (with full channel management, reactions, and file upload) takes a bot token as a stored credential.
- API key - most AI providers (OpenAI, Anthropic, Gemini, Groq, Mistral, Cohere, and more) and many SaaS app nodes (Mailchimp, HubSpot, Notion, and so on).
- Connection string - the Postgres node, guarded by a read-only toggle on by default.
- Service-account JSON - the Google Sheets node signs its own RS256 JWT from a service-account key, so no OAuth flow is required to get started.
- OAuth (Google, Microsoft) - a Google OAuth credential framework lets you connect a Google account once and reuse it across Google Sheets, Gmail, Drive, Calendar, Docs, and Forms nodes without hand-pasting service-account keys. A matching Microsoft OAuth framework covers OneDrive and the Outlook/Office 365 family.
Related
- Workflows - how a node's other config fields get templated.