Variable precedence

When Fetchpier resolves a {{name}} placeholder, it evaluates the name against the active environment merged with any in-flight script mutations. In order of precedence (highest first):

1. In-flight script mutations — values set during this send with fp.environment.set(name, value). These are written to the local layer and persist after the send.
2. The active environment’s local layer — the per-machine overlay (Local column). When both layers define a name, the local one wins.
3. The active environment’s shared layer — the committed, team-shared variables (Shared column).

If no source defines the name, the placeholder stays literal and is flagged in the UI; the request is still sent so you can inspect what would have gone out.

A {{$name}} token is not looked up in the environment at all: the $ prefix is reserved for system tokens, so the name is matched against the built-in set of dynamic variables and, if recognized, resolves to freshly generated data for that occurrence. An unrecognized $-token behaves like any unresolved variable — left literal, flagged, and the send still proceeds. A user variable name beginning with $ is rejected on entry, so a user name can never shadow a system token.

Inside an environment value: {{$env.NAME}}

A separate chain applies within an environment variable’s value, where {{$env.NAME}} reads from the host environment. It is resolved on every send, highest first:

1. The workspace’s .env file, if present. When the key exists there — including with an empty value — that value wins, even over the OS shell.
2. The environment of the running Fetchpier (or fp) process.
3. The empty string, when neither source defines the key. The request still goes out with the hole visible in the outgoing payload.

{{$env.NAME}} is only recognised inside environment variable values. Written directly into a .http URL, header, body, or script it is left literal.

What is not part of precedence

The ephemeral per-send scratch space (fp.variables.*) is separate: it is read and written only through the scripting API, not through {{name}} placeholders, and it is discarded when the send completes. Persisted environment changes made by fp.environment.set survive the send and are visible to later requests — but they always land in the local layer, never in the shared file.

Secrecy does not affect precedence: a secret variable resolves exactly like a plain one, in the same order. It only changes how the value is stored (encrypted) and how it is rendered in logs (masked as {secret:<name>}).