curl bearer token: how to send the Authorization header

To send a bearer token with curl, put it in an Authorization header: curl -H "Authorization: Bearer $TOKEN" https://api.example.com/.... Use double quotes so the shell expands $TOKEN, and leave a space between Bearer and the token. curl's --oauth2-bearer "$TOKEN" option is the built-in alternative: you pass only the token.

curl's options are quoted from its man page and everything curl, shell quoting from the Bash manual's single quotes and double quotes pages, and the header format from RFC 6750, all read 2026-09-28. The Sume examples follow its Authentication docs; its 401 messages are read from the current API code.

How do I pass a bearer token in a curl command?

Keep the token in an environment variable and reference it inside double quotes. RFC 6750 defines the header as the word Bearer, at least one space, then the token, and says a client must not send the token by more than one method in the same request. curl's --oauth2-bearer formats the token according to RFC 6750, so you leave out the Bearer prefix.

Sume API keys follow the same rule: send one as Authorization: Bearer or as x-api-key, never both. How Sume API keys work covers scopes and hosts. Both commands below send the key as a bearer token:

export SUME_API_KEY="sume_live_..."

curl https://api.sume.com/v1/me \
  -H "Authorization: Bearer $SUME_API_KEY"

curl https://api.sume.com/v1/me --oauth2-bearer "$SUME_API_KEY"

Why does curl with a bearer token return 401?

Usually because the header that arrived isn't the one you meant, or the server no longer accepts the token. Add -v to see the header: curl prints each header it sends on a line starting with >, token included, so keep that output out of tickets and screenshots.

A 403 is a different problem: the key was accepted but lacks a permission, as 401 vs 403 vs 404 explains. On the Sume API, each 401 mistake gets its own message in current code:

Should I use double or single quotes around the header?

Double quotes, when the token is in a variable. The Bash manual says single quotes preserve the literal value of each character inside them, so 'Authorization: Bearer $SUME_API_KEY' sends the text $SUME_API_KEY. Inside double quotes, $ keeps its special meaning and the variable expands.

On Windows, everything curl notes there is no support for single quotes, and in PowerShell an alias can run another tool when you type curl, so type curl.exe.

To make a missing variable fail loudly instead of sending an empty token, curl 8.3.0 and later can import it: --variable '%SUME_API_KEY' exits with an error if the variable isn't set, and --expand-header "Authorization: Bearer {{SUME_API_KEY}}" inserts its value.

How do I keep the token safe while testing?

Treat any bearer token the way Sume's docs treat API keys: never in frontend JavaScript, mobile apps, support tickets, or screenshots. Where to store API keys covers the safe places. Two curl habits help while you test:

• -H @file reads headers from a file, one per line, so the token never appears on the command line.
• With -L, curl doesn't pass an Authorization header on to a redirect that goes to another origin unless you add --location-trusted. Downloading a generated video shows where that matters on Sume.