Authentication

Authentication is configured in the Auth tab of the request editor and turns into an ordinary header or query parameter before the request is sent. There are four types — None, Basic Auth, Bearer Token, API Key — plus a fifth mode, Inherit, in which the request takes its credentials from a parent collection. The tab label carries a badge with the current type, so you can tell at a glance without opening it.

The types#

None. Nothing is added. An Authorization header you typed by hand in the Headers tab still goes out — Tetiva leaves it alone.

Basic Auth. Username and Password fields. The request carries Authorization: Basic <base64(username:password)>. The eye button next to the password reveals what you typed when you need to check it.

Bearer Token. Prefix and Token fields. The prefix defaults to Bearer, producing Authorization: Bearer <token>. Replace it with something else — Token, for instance — or clear it entirely, in which case the header contains the raw token value with no prefix and no space.

API Key. Key and Value fields plus an Add to switch.

• Header puts the pair into the request headers as typed.
• Query Params appends the parameter to the URL: the value is encoded, and a parameter of the same name already present in the query string is replaced.

In header mode five names are refused — host, content-length, authorization, connection, transfer-encoding. Sending with one of them fails with an explicit error instead of quietly overwriting a protocol header. If Authorization is what you want, pick Bearer or Basic.

Variables in auth fields#

Every auth field understands {{variables}}: highlighting, completion after {{, and the hover peek behave exactly as they do in a request body. The common setup is a {{token}} reference in the Bearer field with the value refreshed by a post-request script after login.

Tetiva

v0.17.0

Substitution happens after the pre-request script runs, so a token written by pm.environment.set lands in the header during the same run. See Environments and variables and Scripting.

Inheriting from a collection#

A collection has credentials of its own: “Open Details” → the Authorization tab. The list of types is the same, except that None is labelled “No Auth” and nested collections are additionally offered “Inherit from parent”.

A request set to Inherit stores no fields of its own. It searches upward instead:

1. Start with the collection the request belongs to.
2. If that collection is set to anything other than “No Auth”, use its credentials and stop.
3. If it is “No Auth”, ask its parent the same question, and so on toward the root.
4. If nothing is found, the request is sent without authentication.

The walk is capped at 50 levels of nesting. In practice that is a guard against a corrupted tree rather than a working limit — nobody builds folders that deep.

The practical shape that follows: keep shared credentials on the top collection of a service, leave intermediate folders on “No Auth” so they stay transparent to the search, and override only where an endpoint genuinely differs — /auth/login, which needs no token at all, being the usual example.

Order of operations#

Before an HTTP request goes out, Tetiva runs a fixed sequence: variable substitution → pre-request script → authentication → automatic Content-Type.

One consequence surprises people: auth is written last and overwrites whatever was there before. If your pre-request script sets its own Authorization header while the Auth tab is on Bearer, the Auth tab wins. To let the script own the header, set the type to None.

Where auth is not applied#

The Auth tab covers HTTP, GraphQL and the WebSocket handshake.

gRPC requests have no Auth tab: credentials travel as metadata instead — typically an authorization key with a Bearer {{token}} value. Metadata values support variables the same way, but metadata itself is not inherited from a collection: to share one key across a whole collection, set it from the collection's pre-request script with pm.request.metadata.set — see gRPC.

Tetiva ships no dedicated helpers for OAuth 2.0, Digest, AWS SigV4 or NTLM. Schemes that sign the request body are built with a pre-request script: compute the value, store it in a variable, and reference that variable from the Bearer or API Key field.

Where credentials are stored#

Credentials live in the local SQLite database next to the rest of the request and collection fields, in plain text. MCP tools do not hand them out: auth_data is replaced with [redacted] in responses, leaving only whether auth is configured and which type it is — see MCP server.

Folder-level configuration is also covered in Collections.