Skip to main content

​
What is Vault ?

Vault is a local-first encrypted secrets store built into the Requestly desktop app. It lets you:
  • Store secrets locally: API keys, tokens, and passwords encrypted on your machine via OS keychain.
  • Pull secrets from external providers: connect services like AWS Secrets Manager and Azure Key Vault to fetch centrally managed credentials.
  • Reference secrets in requests: use {{vault:key}} syntax in URLs, headers, auth fields, and body.
  • Share collections safely: secret references travel with collections, but values stay on each user’s machine.
Vault requires the Requestly desktop app (Electron) for OS-level encryption via safeStorage. Vault features are not available in the web-only mode.

​
Local Vault

The local vault is available to all users. No sign-in or paid plan is required. Secrets are encrypted at rest using your operating system’s keychain (macOS Keychain, Windows Credential Manager, or Linux Secret Service).

​
Creating a local secret

1

Open the Vault

Click the Vault button in the app footer to open the Vault page.
2

Add a secret

Click Add Secret at the bottom of the Local Secrets table. A new row appears with editable Key and Value cells.
3

Enter key and value

Type a key name (e.g., my-api-key) and a value (e.g., sk-abc123). Press Enter to save. The value masks immediately.

​
Using a vault secret in a request

Reference any vault secret using the {{vault:key}} syntax in any request field:
When you send the request, {{vault:my-api-key}} resolves to the actual value. The resolved value never appears in the editor, console output, collection exports, or cloud sync. Only the {{vault:key}} reference is visible.
Vault secrets appear in the standard {{ autocomplete dropdown alongside environment and collection variables, labeled with a Vault scope badge.

​
Inline editing

Click any key or value cell in the vault table to edit it in place. No modals or separate forms are needed. Changes save automatically on blur or Enter.

​
Deleting a secret

Delete a vault secret from the table. Any {{vault:key}} references to the deleted secret become unresolved immediately.

​
External secret providers

Connect centrally managed secret managers to pull secrets into the vault. External provider secrets share the same {{vault:key}} namespace as local secrets, so your requests don’t need to know where a secret comes from.
  • AWS Secrets Manager: connect an AWS account to fetch and cache secrets, with support for JSON expansion, multiple configurations, and rotation refresh.
  • Azure Key Vault: connect an Azure service principal to fetch secrets, with a vault name per secret so one connection can read from several key vaults.
  • HashiCorp Vault and 1Password (SDK and Connect) are also supported as providers and are rolling out gradually.
External provider integrations require the desktop app, a signed-in Cloud project, and an eligible plan, and are rolling out gradually. Local vault remains fully functional without signing in.

​
Scripting API

Access vault secrets programmatically in pre-request and post-response scripts using the rq.vault API:
Then use {{auth-token}} in the Authorization header. The signing key never leaves the vault. See the full rq.vault reference for the read-only get, has, and toObject methods.

​
Importing from Postman

Requestly preserves {{vault:key}} references when importing Postman collections. No syntax translation is needed.

​
What happens on import

  1. {{vault:key}} references in URLs, headers, auth fields, and body are preserved as-is.
  2. pm.vault.get/set/unset/has calls in scripts are automatically translated to rq.vault.get/set/unset/has.
  3. For each detected {{vault:key}} reference, a local secret is pre-created with an empty value.
  4. A post-import summary lists the pre-created secrets.

​
After import

Open the Vault page. You’ll see the pre-created secret keys with empty values. Fill in the values, and your imported requests will resolve immediately.
Postman collection exports never include vault secret values, only the {{vault:key}} references. You’ll need to re-enter the actual values in your Requestly vault.

​
Namespace and resolution

​
Resolution priority

If the same key exists in both Local Secrets and an external provider (e.g., AWS), the external secret wins. The local secret shows an amber “overridden by duplicate key” warning.

​
Variable hover

Hovering over a {{vault:key}} reference in any editor field shows:
  • The masked value (••••••••)
  • The scope: Vault
  • The source: Local or the external provider name
Unresolved references show an “Unresolved” diagnostic with guidance.

​
Console masking

Vault secret values are always masked in the console and response viewer. You’ll see the {{vault:key}} reference or ••••••••, never the plaintext value.

​
Security model

Linux users: Vault requires a D-Bus Secret Service implementation (GNOME Keyring, KWallet, or equivalent). If no keyring is configured, vault features are disabled but the rest of the app works normally.

​
FAQ

No. Vault requires the desktop app (Electron) for OS-level encryption. This matches how Postman’s vault requires the Desktop Agent.
Local vault secrets persist and continue resolving. They’re tied to your OS user session, not your Requestly account. Previously fetched external provider secrets also remain cached and resolvable. However, you cannot configure new providers or fetch new secrets until you sign back in.
Vault is desktop-only and does not work in CI/CD pipelines. For automated runs, use environment variables or your CI platform’s native secret injection.
No. rq.vault is read-only from scripts for both local and external provider secrets. Only rq.vault.get(), rq.vault.has(), and rq.vault.toObject() are available. To create, update, or delete a secret, use the Vault page. To keep a derived value for the current run, use rq.variables.set().