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

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