## TL;DR

Always send the SearchApi key in the Authorization header instead of the URL. The request becomes GET https://www.searchapi.io/api/v1/search with header Authorization set to Bearer plus your key. You get the same auth with none of the key-in-logs exposure that the query-param form creates.

## Fix

1. Always send the SearchApi key in the Authorization header instead of the URL.
   Expected: You get the expected result; the problem is gone.
2. The request becomes GET https://www.searchapi.io/api/v1/search with header Authorization set to Bearer plus your key.
   Expected: You get the expected result; the problem is gone.

## When to use

- You are setting up or using this SearchApi feature.
- The symptom matches: put the api key in the Authorization header, not the query string.

## When NOT to use

- Unrelated SearchApi issues (different feature, different failure).
- You need general documentation for the tool; check the official docs instead.

## Compatibility

Reported against SearchApi.

## Variant phrasings

### put the api key in the Authorization header, not the query string

## Why it happens

Official docs: the SearchApi docs for the TikTok profile videos engine document two ways to pass the api key, as a query parameter on the URL or in the Authorization header as a bearer value. The docs show the query param form in examples, but every URL with the key in it gets written into server logs, search history, and browser history. The gotcha is that the convenient copy-paste example is the leaky one. Docs: https://www.searchapi.io/docs/tiktok-profile-videos-api

## Edge cases

- If your error message differs even slightly, this is probably a different issue; search the exact text.
- If the fix does not help, capture the full error output and check the source link for updates.