## TL;DR

If you connect with a raw websocket client that cannot set headers, pass it as the apiKey query parameter on the URL instead (wss://api.browsercat.com/connect?apiKey value [your key]). Put your BrowserCat API key in the Api-Key header on the websocket connect call - not in an Authorization Bearer header.

## Fix

1. If you connect with a raw websocket client that cannot set headers, pass it as the apiKey query parameter on the URL instead (wss://api.browsercat.com/connect?apiKey value [your key]).
   Expected: You get the expected result; the problem is gone.

## When to use

- You are dealing with this situation.
- The symptom matches: BrowserCat API key goes in the Api-Key header (or apiKey query param) - not Authorization.

## When NOT to use

- Unrelated issues with a different cause.
- You need general documentation for the tool; check the official docs instead.

## Compatibility

Reported per the linked source. Source: https://www.browsercat.com/docs.

## Variant phrasings

### BrowserCat API key goes in the Api-Key header (or apiKey query param) - not Authorization

## Why it happens

Official BrowserCat docs (Overview, Playwright Testing, CLI Launch Args): BrowserCat authenticates the websocket connection with an Api-Key header (wss://api.browsercat.com/connect with headers {'Api-Key': [your key]}), or an apiKey query parameter on raw websocket URLs. It is not a Bearer token in an Authorization header. Several docs examples use the header name in different cases (Api-Key, api-key) - HTTP headers are case-insensitive so both work.

## 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.

## Source

https://www.browsercat.com/docs