AUTHENTICATION

Auth Inheritance

Set authentication once at the collection or folder level and let child requests inherit it automatically — no need to repeat credentials on every request.

How Inheritance Works

Auth cascades down the collection hierarchy:

Collection (Bearer Token)
├── Folder A (inherits from collection)
│   ├── Request 1 (inherits → uses Bearer Token)
│   └── Request 2 (inherits → uses Bearer Token)
├── Folder B (API Key override)
│   ├── Request 3 (inherits → uses API Key)
│   └── Request 4 (own Basic Auth → uses Basic Auth)
└── Request 5 (inherits → uses Bearer Token)

The "Inherit from parent" toggle on requests and folders enables this behavior. When enabled, the node looks up the tree for auth configuration instead of using its own.

Chain Resolution

When a request is sent with inheritAuth: true, the resolution algorithm walks up the tree:

Check the request — if inheritAuth: false, use this node's auth config

Check the parent folder — if inheritAuth: false, use that folder's auth

Continue up through nested folders...

Reach the collection root — use the collection's auth config

Default behavior: New requests have inheritAuth: false (opt-in). You must explicitly enable inheritance for a request to look up the chain. This prevents unintended auth propagation.

Setting Collection Auth

To set auth at the collection level:

Click the collection name in the sidebar to open the Collection Editor

Navigate to the Auth sub-tab

Select the auth type and fill in credentials — this becomes the default for all inheriting children

Setting Folder Auth

To set auth at the folder level:

Click the folder name in the sidebar to open the Folder Editor

Navigate to the Auth sub-tab

Configure the auth type — requests inside this folder (with inheritance enabled) will use this config

Folders can also inherit from their parent by enabling the "Inherit from parent" toggle on the folder's auth tab.

Request Inherit Toggle

On the request's Auth tab, you'll see two options:

Inherit from parent

Uses auth from the nearest ancestor (folder or collection) that has inheritAuth: false. The auth type selector is hidden when this is active.

Direct configuration

Configure auth directly on this request (None, Basic, Bearer, API Key, OAuth2, AWS SigV4, Digest). This is the default for new requests.

Breaking the Chain

Set inheritAuth: false at any level to stop the lookup. That node uses its own auth and doesn't look further up the tree.

Example — folder override:

Collection (Bearer: {{main_token}})
└── Admin Folder (inheritAuth: false, API Key: {{admin_key}})
    ├── Request A (inheritAuth: true → uses API Key)
    └── Request B (inheritAuth: true → uses API Key)

The Admin Folder breaks the chain — its children inherit the folder's API Key, not the collection's Bearer token.

Examples

Example: Collection-wide Bearer Token

Collection "My API" → Auth: Bearer {{api_token}}

All requests with inheritAuth: true automatically
get: Authorization: Bearer <resolved token>

Example: Folder Override for Sub-API

Collection "Platform" → Auth: Bearer {{user_token}}
└── Folder "Payments API" → Auth: API Key (X-API-Key: {{pay_key}})
    └── POST /charges (inheritAuth: true → uses X-API-Key)

Safety note: If request.auth is undefined (e.g. from old saved data), the resolution falls back to { type: 'none' }. This prevents errors from corrupt or legacy request data.

Auth Overview →