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

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 value [your key]). A 401 at connect time almost always means the key is in the wrong header, not that the key is bad.

Context: 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.

Matched source

Source: Source: https://www.browsercat.com/docs Original query: "BrowserCat API key goes in the Api-Key header (or apiKey query param) - not Authorization" Key terms: apikey, authorization, browsercat, goes, header, param, query