Authentication
Fetchpier applies authentication as a step in the send pipeline, injecting the right header or query parameter for the scheme you choose.
| Scheme | Effect |
|---|---|
| None | No auth header or query parameter is added. |
| Bearer token | Adds Authorization: Bearer <token>. |
| Basic | Adds Authorization: Basic <base64(user:password)> (UTF-8 safe). |
| API key (header) | Adds <key>: <value> as a header. |
| API key (query) | Appends ?<key>=<value> to the URL. |
Auth values support {{variable}} interpolation, so secrets live in environment variables rather
than hard-coded in the request.
The selected scheme is persisted with the request and restored on reopen — the auth type and field mapping survive a save / close / reopen round-trip, for all schemes. The header or query parameter the scheme generates appears read-only in the headers (or parameters) surface, attributed to the Auth panel and editable only there. While a scheme is active it owns that name: a manually-added header or parameter with the same name is not shown and is not sent — the Auth panel is the single source for it. Other hand-authored headers remain fully editable.
The persisted form keeps {{variable}} references verbatim — resolved secret values never touch the
file, and stored activity-log snapshots mask secret auth values. A request configured this way sends
identically from the desktop and from the command-line runner.