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 [your value] 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 [your value] 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.

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.

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. Resolved: Put your BrowserCat API key in the Api-Key header on the websocket connect call - not in an Authorization Bearer header. So: pw.chromium.connect('wss://api.browsercat.com/connect', { headers: { 'Api-Key': [your key] } }). 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 [your value] key]). A 401 at connect time almost always means the key is in the wrong header, not that the key is bad. Source: https://www.browsercat.com/docs