SECRET VAULT
Secret Sets
Bridge your encrypted vault secrets to {{variable}} placeholders — switch between credential profiles without changing your requests.
What Are Secret Sets
Secret Sets bridge vault keys to {{variable}} placeholders. A secret set is a named group of mappings — each mapping connects a vault key to a variable name used in your requests.
Vault key → variableName
Each entry maps a secret's name in the vault to a {{placeholder}} that your requests use
Multiple profiles
Create separate sets for dev keys vs prod keys — switch between them without editing requests
Only one active at a time
The active set determines which secrets resolve during request execution
~/.openpost/global/config.json. The mappings themselves are not encrypted — only the vault values they point to are.
Creating a Secret Set
Create a new secret set in three steps:
Mapping Entries
Each entry in a secret set creates a bridge between a vault key and a variable placeholder:
| Field | Description | Example |
|---|---|---|
| Vault Key | The secret's name in the vault | stripe_secret |
| Variable Name | The {{placeholder}} name | api_key |
Resolution example:
Adding entries:
{{placeholder}} to use in requests)Enabling/Disabling Entries
Each entry has an enabled toggle that controls whether the mapping resolves at runtime:
Enabled
Mapping is active — {{variable}} resolves to the vault value. Included in secret scrubbing.
Disabled
Mapping exists but doesn't resolve. The {{variable}} remains unresolved. Not included in scrubbing.
Active Secret Set
Select the active secret set from the vault dropdown in the top bar — it sits next to the environment selector.
Only one active at a time
The active set's variables participate in interpolation during request execution
Switching sets changes resolution
Same request, different active set = different secrets injected
No active set = no vault secrets
If no set is selected, vault secrets are not used in interpolation
collection vars < global env < vault secrets < local env. Vault secrets override global environment variables but local environment always wins.
Use Cases
Multiple API key profiles
Create a "Dev Keys" set that maps to test API keys and a "Prod Keys" set that maps to production keys. Same {{api_key}} placeholder, different resolved values.
Per-client credentials
One set per client with their specific tokens. Switch between clients by selecting a different active set — no request editing needed.
Secret rotation
Update the vault value when a key rotates — all mappings automatically use the new value. Variable names stay the same, requests keep working.
Team sharing
Share the secret set configuration (key mappings) via git in config.json. Each developer has their own vault with their own values — the mappings are the shared contract.