How to Test an API with a Bearer Token

Send the token in the Authorization header as Bearer followed by one space and the token. In API Test Lab, choose Bearer authentication and enter the token value without the word Bearer.

Prerequisites

Use an API you are authorized to access, its documented endpoint, and a valid short-lived test token with the required scope. Create and verify an API Test Lab account. Free lists Bearer authentication and 100 API tests per month; see pricing.

A token authenticates a caller but does not guarantee permission for every resource. Use HTTPS for real credentials. Do not put tokens in URLs, screenshots, shared collections, or analytics.

Build the request

Open the Test Lab, select the endpoint's method, enter its URL, and open Auth. Select Bearer and paste only the token value. Avoid also setting an Authorization header manually, which makes it unclear which value is sent.

Equivalent request shape, using a placeholder endpoint and token:

GET /v1/profile HTTP/1.1
Host: api.example.com
Authorization: Bearer YOUR_TEST_TOKEN
Accept: application/json

Replace the host, path, and token with your API's values. Expected status and body depend on that API's contract.

Run a reproducible local example

This Node.js fixture uses a deliberately public test string, not a real credential. Save as bearer-demo.mjs and run node bearer-demo.mjs.

import { createServer } from 'node:http';
createServer((req, res) => {
  const allowed = req.headers.authorization === 'Bearer demo-token';
  res.writeHead(allowed ? 200 : 401, {
    'Content-Type': 'application/json',
  });
  res.end(JSON.stringify(allowed ? { ok: true } : { error: 'unauthorized' }));
}).listen(3002, '127.0.0.1');

Then run this terminal request:

curl --include http://127.0.0.1:3002/ \
  --header 'Authorization: Bearer demo-token'

Expected result: HTTP 200 and {"ok":true}. Remove the header or change the token to get HTTP 401 and {"error":"unauthorized"}. This fixture is for a terminal test: it does not enable browser CORS. In the hosted product, use an authorized reachable HTTPS staging API; localhost requests can be blocked by browser connectivity rules.

Inspect success and failure

Check status, response headers, body, and timing. A 200 alone does not prove the returned user or resource is correct. Verify the expected identity and fields without copying sensitive values into reports.

• 401: check expiration, missing header, whitespace, issuer, and whether you pasted Bearer twice.
• 403: check scopes, roles, resource ownership, and gateway policy. A valid token may lack permission.
• Browser network/CORS error: this is not proof of a bad token; establish connectivity first.
• Unexpected user data: check which account issued the token and whether the environment is correct.

Repeat safely

Test a valid token, an invalid token, and a token without the required scope against your staging API. Keep expected status and body assertions with each case. Saved requests require a plan with a saved-request allowance; do not save real tokens into shared examples.

See REST response validation and the getting-started workflow. Start testing free when you are ready to inspect your own endpoint.