API Authorization in Postman: API Keys, Bearer and OAuth 2.0

Where authorization is configured

Every request, folder and collection in Postman has an Authorization tab. Postman turns the selected auth type into the right header or query parameter for you.

The main rule: configure authorization at the collection level. New requests default to Inherit auth from parent, taking settings from their folder or collection. When the token changes, you update it in one place instead of in every request.

If a specific request needs no authorization, such as the login endpoint, set it to No Auth.

API Key

The simplest option: a static key the service issues in its dashboard.

• Key — the header or parameter name from the API docs, for example X-API-Key;
• Value — the key itself, preferably as a variable: {{api_key}};
• Add to — Header or Query Params.

Prefer the header: a key in the URL ends up in history and in server and proxy logs.

Bearer Token

Used when the API issues an access token, most often after login. Postman adds this header:

Authorization: Bearer <token>

Put the variable {{access_token}} in the Token field. The token can be saved automatically: in the login request's Scripts tab (the post-response section, called Tests in older versions), add:

const data = pm.response.json();
pm.environment.set("access_token", data.access_token);

After a login, every request in the collection gets the fresh token.

OAuth 2.0

For OAuth 2.0, Postman can obtain the token itself. Under Configure New Token, pick a Grant Type:

The key fields are Auth URL, Access Token URL, Client ID, Client Secret, Scope and Callback URL. For browser-based flows, enable Authorize using browser and register the callback URL Postman shows in the OAuth app settings on the provider's side.

Click Get New Access Token, sign in and click Use Token. Newer Postman versions can refresh the token automatically when the server issues a refresh token; check that setting in your version.

Refreshing tokens with a pre-request script

If the API issues short-lived tokens and built-in refresh is not available, add a collection-level pre-request script. It runs before every request and fetches a new token only when the old one has expired:

const expiresAt = Number(pm.environment.get("token_expires_at") || 0);

if (Date.now() > expiresAt) {
  pm.sendRequest({
    url: pm.environment.get("token_url"),
    method: "POST",
    header: { "Content-Type": "application/x-www-form-urlencoded" },
    body: {
      mode: "urlencoded",
      urlencoded: [
        { key: "grant_type", value: "client_credentials" },
        { key: "client_id", value: pm.environment.get("client_id") },
        { key: "client_secret", value: pm.environment.get("client_secret") }
      ]
    }
  }, (err, res) => {
    if (err) { console.error(err); return; }
    const data = res.json();
    pm.environment.set("access_token", data.access_token);
    pm.environment.set("token_expires_at", Date.now() + (data.expires_in - 60) * 1000);
  });
}

On the collection, choose Bearer Token with the value {{access_token}}. The 60-second margin keeps the token from expiring mid-request. If the provider does not return expires_in, refresh the token when you get a 401 response.

Keeping secrets out of shared workspaces

Everyone in a shared workspace can see its contents, so:

• Keep secrets in environment variables, not in requests. A variable has an initial value, which syncs to the team, and a current value, which stays on your machine. Put secrets in the current value only.
• Mark variables as secret so the value is masked in the interface.
• Use Postman Vault where available: secrets stay local and are referenced as {{vault:name}}.
• Do not export collections and environments with real tokens, especially into a repository.
• Separate environments: dev, staging and production with different keys, and give production keys to as few people as possible.
• If a key does leak, revoke it with the provider rather than just deleting it from Postman.