API keys and tokens, encrypted and out of sight
Store the API keys, tokens and credentials your backend needs as project secrets. They're encrypted at rest, never shown again after you save them, and decrypted only at the moment a workflow step uses them.
The same task, three ways
Every task works three ways, and all of them change the same project. Here's one: store a Stripe key and use it from a workflow.
The Anythink dashboard
Save the key once, then reference it by name in a workflow step.
The Anythink CLI
The value is prompted for, so it never lands in your shell history.
$ anythink secrets create STRIPE_SECRET_KEY$ anythink secrets list- ✓STRIPE_SECRET_KEY stored, encrypted with AES-256-GCM
- ✓list shows names and dates, never values
Claude, through MCP
Keep the value out of chat: store it in the dashboard or CLI, then ask the assistant to use it.
you › “Add a step to the Sync Stripe customers workflow that calls the Stripe customers API, using the STRIPE_SECRET_KEY secret as a bearer token.”
- ✓Added a Call An API step
- ✓Authorization header references {{ $anythink.secrets.STRIPE_SECRET_KEY }}
- ✓The secret's value was never read or shown
Secrets your workflows can use, and nobody can read
One encrypted store for every credential your backend touches: AI provider keys, payment keys, webhook tokens and third-party API keys.
Encrypted at rest with AES-256-GCM
Every value is encrypted before it's stored, using AES-256-GCM with a key derived through PBKDF2 (600,000 iterations). The plaintext never sits in your database.
Write once, never shown again
After you save a secret, the dashboard, API and CLI show only its name and dates, never the value. To change it, you replace it.
Use them in any workflow step
Write {{ $anythink.secrets.STRIPE_SECRET_KEY }} in a Call an API header, a script or an integration step. The value is decrypted inside the workflow worker when that step runs, and nowhere else.
Shared with the people who need them
Project administrators see every secret. Everyone else sees only the secrets shared with them, either read-only or editable.
Controlled by roles
Reading, creating, updating and deleting secrets are separate permissions, so a role can use the backend without ever managing its credentials.
Every stored credential, the same protection
Integration OAuth credentials, push notification service accounts and Apple in-app purchase keys are encrypted the same way, so nothing sensitive is stored in plain text.
In practice
Store a key once, then use it from a workflow
anythink secrets create STRIPE_SECRET_KEY # prompts for the value, so it never lands in your shell history
What teams keep in secrets
AI provider keys
Keep a Claude, OpenAI or Grok key in one place and reference it from every workflow that summarises, translates or analyses. To rotate it, update the secret, not each workflow.
Payment and webhook credentials
Stripe keys, webhook signing secrets and partner API tokens live in one place instead of being pasted into each workflow. Send them in a header or the body: Call an API logs header names, never their values.
Per-environment configuration
Staging and production projects each hold their own secrets under the same names, so a workflow promoted with anythink migrate picks up the right credentials in each.
Frequently Asked Questions
How are secrets stored in Anythink?
Each value is encrypted with AES-256-GCM, using a key derived through PBKDF2 with 600,000 iterations, before it's written to the database. Only the encrypted form is stored.
Can I see a secret's value after saving it?
No. The dashboard, API and CLI list a secret's name and dates but never its value. To change a value, you update the secret.
How do I use a secret in a workflow?
Reference it as {{ $anythink.secrets.KEY_NAME }} in any step field, such as an API header, a script or an integration setting. It's decrypted inside the workflow worker only when that step runs.
Who can read or manage secrets?
Project administrators see all secrets. Other users see only the secrets shared with them, either read-only or editable. Creating, updating and deleting secrets are separate role permissions.
Is this a replacement for environment variables?
For anything your Anythink backend uses, yes. Secrets live with the project, so workflows, integrations and scripts reference them by name instead of each needing its own configuration.
Do secrets show up in workflow logs?
Not when they're sent in a header or the request body: the Call an API step logs header names but not their values, and doesn't log the body. Avoid putting a secret in a URL, because the step logs the URL it calls.
Still have questions?
Get in TouchMore in the same project
Every feature reads from the same data model, so each one you add works with the rest.
Ways to build with it
The dashboard, the CLI, MCP and the SDK, plus guides for moving from other platforms.
Who it's for
How founders, agencies and enterprise teams use Anythink.
Documentation
Guides and reference at docs.anythink.cloud.
Ready to go?
Create an account and start building