Bearer token vs API key: what's the difference?

A bearer token and an API key aren't alternatives. Bearer is a way of sending a credential, in an Authorization: Bearer <token> header; an API key is one kind of credential, a secret you create and revoke yourself. So an API key can travel as a bearer token. An OAuth access token is a different credential that is also sent as a bearer token, but it is issued to an app for a set scope and duration.

The definitions are quoted from RFC 6750, RFC 6749 and RFC 9110; the Sume details come from its Authentication and MCP OAuth and API keys docs. All were read on 2026-09-28.

What is a bearer token?

RFC 6750, the OAuth 2.0 bearer token standard, defines it by one property: any party in possession of the token, the bearer, can use it in any way that any other holder can, without proving possession of a cryptographic key. The name describes how the token is used, not what it is. The standard's example sends it in the Authorization header with the Bearer scheme.

Because whoever holds the token can use it, RFC 6750 says clients must always use TLS (https) when they send one.

GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer mF_9.B5f-4.1JqM

Is an API key the same as an access token?

No, though both can be sent as bearer tokens. RFC 6749 describes an OAuth access token as a string representing an authorization issued to a client, for specific scopes and durations of access granted by the resource owner, such as the end user. RFC 6750 recommends that token servers issue short-lived bearer tokens, one hour or less. A Sume API key, by contrast, is one you create in the API Keys dashboard for one workspace, with scopes fixed at creation, and in current code it works until you revoke it.

Sume's hosted MCP server accepts both, and its docs say they are not interchangeable credentials: an MCP OAuth token is not a Sume API key.

Should I send an API key as Bearer or x-api-key?

Whichever the API documents. Authorization is the standard HTTP header a client uses to authenticate itself to a server; x-api-key is a header name an API defines for itself. RFC 6750 adds a rule worth copying for any credential: don't send the token by more than one method in the same request.

Sume accepts its key either way and enforces that rule. A request that carries both headers is rejected with 401 unauthorized and the message Send only one API key credential. How Sume API keys work covers scopes and hosts.

Can I pass an API key in the URL?

Don't. RFC 6750 says bearer tokens should not be passed in page URLs, for example as query string parameters, because browsers, web servers and other software may not adequately secure URLs in the browser history and server logs. It does document an access_token query parameter, but says not to use it unless the header and the body are both impossible, and calls its use not recommended.

Sume offers no query-parameter option: in current code, the API reads the key only from the x-api-key and Authorization headers, and a request with neither is told Missing API key. Send x-api-key or Authorization: Bearer. If a key does land in logs or chat history, the docs say to rotate it; Exposed API key? walks through the swap.