# Brave Search API auth: X-Subscription-Token header, not Bearer

## TL;DR

Authenticate Brave Search API calls like this: curl "https://api.search.brave.com/res/v1/web/search?q=..." \ -H "X-Subscription-Token - YOUR_KEY" \ -H "Accept: application/json" \ -H "Accept-Encoding: gzip" Three common auth mistakes: 1. Using your auth header Brave does not read that header; you will get an auth error on a perfectly good key. Putting the key in ?apikey value or similar query params.

Use this when you run into the situation in the title.

**When not to use this skill:** unrelated tasks. It covers only the procedure above.

## Compatibility

The steps above apply to the commands named in them. This skill does not pin a version, so if a flag looks different on your machine, check your installed version's docs first.

## Details

2. Not supported, and it leaks the key into logs. 3. Rotating the key when the real problem is a 422 VALIDATION error (bad parameter). Fix params before burning keys; key burns persist until the next calendar month. Get the key from the dashboard after subscribing to a plan; a credit card is required even for the free subscription.

Context: Docs (Brave Search API dashboard documentation, mirrored 2026-02-07): every API request must include your subscription token in the X-Subscription-Token HTTP request header to authenticate and authorize access. Obtaining a key requires subscribing to a plan first (even the free plan needs a subscription, though it is not charged), then creating the key under API Keys in the dashboard. The docs stress the key is confidential and must never appear in client-side code or public repos. Agents defaulting to your auth header an ?apikey value query parameter get auth failures on perfectly good keys.