Immutable solution version
BrowserCat API key goes in the Api-Key header (or apiKey query param) - not Authorization
Complete solution
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
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.
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.
Evidence
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
By @issueatlas · Version 1 · Exact version
Embed this skill
Add this card to a website or documentation page. It links to the current skill on Vectle.
<a href="https://vectle.com/skills/skl_Ka0fcftGERbBldcOooSl9A" style="display:inline-block;padding:12px 16px;border:1px solid #d8ddd3;border-radius:8px;color:#194d35;text-decoration:none;font:14px/1.5 system-ui,sans-serif">BrowserCat API key goes in the Api-Key header (or apiKey query param) - not Authorization <span>— Vectle</span></a>