Variable Priority

Priority Chain

When multiple sources define the same variable name, the highest priority source wins. Resolution happens at send time — the final value is what gets interpolated into your request.

Priority (lowest → highest)

① Lowest Collection Vars

② Global Env

③ Vault Secrets

④ Highest Local Env

Key rule: Local environment ALWAYS wins — useful for per-developer overrides without affecting shared configs.

Collection Variables (Lowest Priority)

Defined in the Collection Editor → Overview tab. These are scoped to the collection and shared across all its requests.

Defined in Collection Editor → Overview tab

Shared across all requests in the collection

Only available to requests within that collection

Overridden by everything else in the chain

Good for: Base URLs, API versions, common paths — values that are constant across the collection but might differ between environments.

Global Environment

Selected from the environment dropdown (global scope). Stored in ~/.openpost/global/environments.json and shared across all workspaces.

Shared across all workspaces on your machine

Overrides collection variables

Overridden by vault secrets and local environment

Good for: Shared credentials, company-wide endpoints, team-standard API keys that aren't secret enough for the vault.

Vault Secrets

From the active Secret Set in the built-in vault. Secret entries map vault keys to {{variableName}} placeholders.

Overrides collection variables and global environment

Overridden by local environment only

If the vault is locked, secret resolution is silently skipped

Secret values are automatically scrubbed from persisted history

Good for: API keys, passwords, tokens, and any value that shouldn't be stored in plain text. Secrets are encrypted at rest with AES-256-GCM and never written to history files.

Local Environment (Highest Priority)

Selected from the environment dropdown (local scope). Workspace-specific, stored in .openpost/environments.json.

ALWAYS wins over all other sources

Workspace-specific — different per project

Can override vault secrets for testing (e.g., use a test API key locally)

Good for: Developer-specific overrides, feature branch URLs, debug tokens, local development endpoints.

Conflict Resolution

When the same variable name exists in multiple sources, the highest priority source wins silently. This is by design — it enables intentional overrides without disrupting workflows.

No warning shown — allows intentional layered configuration

Hover over {{var}} in the editor to see which source provided the value

The Actual Request tab shows fully resolved values for debugging

Tip: If a variable isn't resolving as expected, check the Actual Request tab after sending — it shows the final interpolated URL, headers, and body.

Examples

Example 1: Development override

Variable: {{base_url}}

Collection vars:https://api.example.com

Local env:http://localhost:3000 ✓ wins

During development, local env overrides the production URL without changing the collection.

Example 2: Test key override

Variable: {{api_key}}

Vault secret:sk-prod-abc123...

Local env:sk-test-xyz789... ✓ wins

Local env overrides the vault production key with a test key for local testing.

Example 3: No conflict

Variable: {{version}}

Collection vars:v2 ✓ used (only source)

When only one source defines the variable, that value is used directly.

Full resolution table

Source	{{base_url}}	{{api_key}}	{{version}}
Collection Vars	https://api.example.com	—	v2
Global Env	https://staging.example.com	—	—
Vault Secrets	—	sk-prod-abc123	—
Local Env	http://localhost:3000	sk-test-xyz789	—
Resolved ✓	http://localhost:3000	sk-test-xyz789	v2

For {{version}}, only collection vars defined it — so that value is used. For the others, local env wins.