Bearer tokens and API keys in Postman, explained

Most real APIs won't answer until you prove who you are. Send a request without credentials and you'll get a 401 Unauthorized, however perfect the rest of the request is.

The two most common ways to prove who you are are API keys and bearer tokens. Both are just pieces of text you send with the request, but they work a little differently.

API keys: a long-lived password for software

An API key is a long, random string that identifies an application or a project. You typically get one from a developer portal or settings page, and it stays the same until someone revokes it.

APIs expect the key in one of two places:

GET /reports/daily
x-api-key: 5f3c9a1e8b7d4c2a

or, less securely, as a query parameter:

GET /reports/daily?api_key=5f3c9a1e8b7d4c2a

The header name varies: x-api-key, api-key and apikey are all common. Check the documentation.

Bearer tokens: a temporary pass for a user

A bearer token usually represents a signed-in user. You get it by logging in, often by sending a username and password, or by going through an OAuth sign-in flow, and it expires after a while: minutes, hours or days.

It's always sent in the Authorization header, with the word Bearer and a space in front of it:

GET /customers/42
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

"Bearer" means "whoever carries this token is allowed in", like a ticket at a concert. That's why you should treat tokens like passwords.

Many bearer tokens are JWTs (JSON Web Tokens): three chunks of text separated by dots. They aren't encrypted, only encoded, so you can decode one (for example at jwt.io) to see who it belongs to and when it expires. That's handy when you're working out why a request fails.

API key or bearer token?

Some APIs ask for both: an API key to identify the app and a bearer token to identify the user.

Sending credentials in Postman

You could type the header by hand on the Headers tab, but the Authorization tab is easier and avoids typos.

A bearer token

1. Open the request's Authorization tab.
2. Set Auth Type to Bearer Token.
3. Paste the token into the Token field. Don't type the word "Bearer": Postman adds it.

An API key

1. Set Auth Type to API Key.
2. Enter the header name in Key (for example x-api-key) and the key in Value.
3. Set Add to to Header (or Query Params if the API wants it in the URL).

Click Send. To see the exact header Postman sent, open the Console at the bottom of the window.

Watch out

A missing space or an extra one breaks bearer authentication. Authorization: Bearer abc works; Authorization: Bearerabc and Authorization: abc don't. Using the Authorization tab avoids this completely.

Stop pasting the token into every request

Tokens expire, so pasting the same token into twenty requests means updating twenty requests tomorrow. Do this instead:

1. Create an environment (for example "Test") and add a variable called token.
2. Open your collection, go to its Authorization tab, choose Bearer Token, and enter {{token}}.
3. In each request's Authorization tab, leave Auth Type on Inherit auth from parent.

When the token expires, you update one variable and every request picks it up.

Tip

Set the variable type to secret so the value is masked on screen, and keep real tokens in the current value only. Initial values are shared when you share a collection or environment.

What to test

For any protected endpoint, these checks are worth running:

• No credentials → 401
• Wrong or malformed token → 401
• Expired token → 401, ideally with a message saying it's expired
• Valid token, wrong user (for example someone else's order) → 403, or 404 if the API hides other people's data
• Valid token, right user → success

The last two are where real security bugs hide. If you can read or change another user's data with your own token, report it straight away.

In the authenticate-request exercise you set up both an API key and a bearer token to reach a protected endpoint, with feedback on each header.