.env files

.env files define environment-specific variables. Switch between them using the environment selector in the header.

Syntax

Simple KEY = VALUE pairs, one per line. Whitespace around = is ignored. Lines starting with # are comments.

dev.env

BASE_URL    = https://jsonplaceholder.typicode.com
API_TOKEN   = dev-token-abc123
TIMEOUT     = 5000

# Secrets — shown as •••• in the env selector tooltip
API_SECRET  = super-secret

Multiple environments

Create one .env file per environment and switch with the env selector in the header.

envs/
  dev.env       → green indicator
  staging.env   → amber indicator
  prod.env      → red indicator (guarded)

Files named prod or production trigger a confirmation prompt before switching — a safety net against accidentally running destructive requests against production.

Using variables

Reference any variable from the active .env file using {{VARIABLE_NAME}} in requests:

GET {{BASE_URL}}/users
Authorization: Bearer {{API_TOKEN}}

File-level variable overrides

Define variables inline at the top of any .http or .flow file with @key = value. These override .env variables with the same name.

@baseUrl     = {{BASE_URL}}
@contentType = application/json

GET {{baseUrl}}/health

Sensitive variable masking

Any variable whose name contains secret, token, key, or password is automatically masked in the UI tooltip. Enable Redact sensitive headers in Settings → History to also mask them in the request history log.

Runtime overrides — .env.local

Each <name>.env can have a sibling <name>.env.local that overrides it at runtime. Sendpad writes to this file via the @persist directive, and merges it on top of the base env automatically.

envs/
  dev.env          ← you author this, commit it
  dev.env.local    ← Sendpad writes runtime values here
  prod.env         ← persists are disabled for prod-named envs

The env selector shows a +N local badge when an env has runtime overrides. Delete the .env.local file from the file tree to reset.

Sendpad auto-adds *.env.local to your workspace .gitignore when one exists — runtime values never leak into git.

How @persist writes to .env.local

### Login
POST {{BASE_URL}}/auth/login
Content-Type: application/json

{ "email": "dev@example.com", "password": "..." }

# @extract token = $.access_token
# @assert  status == 200

# Promote the extracted token into dev.env.local
# @persist token

# Or write a specific value
# @persist LAST_LOGIN = "2026-04-12"

Rules:

• Persists run after all @asserts — a failing assertion aborts every persist in that step.
• Persists are silently skipped for envs named prod or production.

Variable resolution order

When a request runs, variables resolve in this priority:

1. Extracted flow variables (# @extract) — highest priority
2. .env.local overrides
3. .env file variables (including @extends chain)
4. File-level variables (@key = value)

Sensitive variables

Put secrets in <name>.env.local — leave <name>.env for shared config. Sendpad auto-creates a .gitignore for *.env.local on first write, so values never leak into git.

A variable is treated as sensitive if:

• its name contains token, secret, key, password, passwd, pwd, or auth, or
• it appears only in .env.local (file split = intent signal).

Sensitive vars are masked as •••• in the env tooltip and value-redacted from request history regardless of header name. Toggle Screencast mode (⌘⇧H) to also disable Copy buttons during demos. There’s no directive to learn — the file split does the work.

@extends — inherit from another .env (Pro)

Compose env files hierarchically. A child env inherits all keys from the parent and can override any of them:

base.env

BASE_URL = https://api.example.com
TIMEOUT  = 5000
LOG      = info

dev.env

@extends base.env

BASE_URL = https://dev-api.example.com   # override
LOG      = debug

Multiple extends chain left-to-right; later entries win:

dev.env

@extends base.env
@extends defaults.env

Paths are resolved relative to the .env file. See the Env Inheritance feature doc for layering rules and how .profile files compose multiple envs.

.profile — stack envs into a profile (Pro)

A .profile file assembles multiple .env files into a single named profile. Selecting a profile merges them in order, so you can compose per-region + per-role envs without maintaining giant dev.env files.

See the .profile reference.