BrowserCat API

Name: BrowserCat API
Brand: BrowserCat API
Availability: InStock

★ Only Publicly Available OpenAPI DocumentDeveloper ToolsTesting QaapiKey23 EndpointsREST

For Agents

Spin up a managed Chromium session over websocket via /connect and audit usage, sessions, and billing through the REST API. Useful for scraping, end-to-end testing, and PDF generation agents.

Install Jentic One Beta

Connect the BrowserCat API to your agent

Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the BrowserCat API, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.

Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.

Step 1: Jentic One Host machine

# On the machine that will host your Jentic One instance:
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh

Step 2: Agent machine

# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh
jentic register       # connects your agent to your Jentic One instance

Jentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.

Capabilities

What an agent can do with BrowserCat API.

Open a managed headless Chromium session by upgrading a websocket connection on /connect

Mint, list, rotate, and revoke API keys scoped to specific projects or environments

Inspect per-session usage with the events endpoint to see exactly which actions ran in a script

GET STARTED

Start building with BrowserCat API

Explore with Jentic

View OpenAPI Document

Jentic publishes the only available OpenAPI specification for BrowserCat API, keeping it validated and agent-ready. BrowserCat is a managed headless browser service that exposes Chromium instances over a websocket connection so Playwright, Puppeteer, and Selenium clients can run scripts without operating their own browser fleet. The REST API alongside the websocket handles API key management, billing and subscriptions, and detailed usage reporting at the session and event level so teams can audit which scripts ran, how long they took, and what they cost.

Use Cases

Patterns agents use BrowserCat API for, with concrete tasks.

★ Cloud-Hosted Playwright and Puppeteer

Engineering teams point their Playwright or Puppeteer client at the /connect websocket so scripts run on BrowserCat's managed Chromium fleet instead of self-hosted browsers. Each connection is a fresh isolated session, so flaky local installs and Docker image upkeep disappear. The REST API mints scoped API keys per CI environment and the usage endpoints show exactly which test runs consumed which session minutes.

POST /auth/keys to mint a CI key, then connect a Playwright client to wss://api.browsercat.com/connect with the key in the api-key header

Per-Session Usage Auditing

Platform teams running BrowserCat across many internal projects need to attribute cost and behaviour back to the team that owns each script. The /usage/sessions and /usage/sessions/{sessionId}/events endpoints expose the full breakdown — which key opened the session, how long it lasted, and the events fired inside the script. The agent ingests these into a BI tool to chargeback teams or alert on anomalous usage.

GET /usage/sessions for the last 24 hours, then for each session GET /usage/sessions/{sessionId}/events and aggregate by api-key id

Automated Key Rotation and Revocation

Security teams treat BrowserCat keys like any other production secret and rotate them on a schedule. The agent uses POST /auth/keys to issue a replacement key, deploys it through the secret manager, and DELETE /auth/keys/{keyId} to revoke the old one once traffic has cut over. If a key ever leaks, the same DELETE call kills it within seconds.

POST /auth/keys to mint a new key, deploy it, then DELETE /auth/keys/{old-key-id} to revoke the previous key

AI Browser-Use Agent Through Jentic

An AI agent that needs to browse a live web page uses Jentic to discover and call BrowserCat without holding the raw API key. The agent searches for 'open a headless browser session', loads the connect schema, and the websocket session is brokered with a Jentic-vaulted credential. This is a clean separation between the LLM-driven decision logic and the cloud browser substrate.

Use Jentic to search 'open a headless Chromium session', load the browsercat.com operation, and connect a Playwright client through the brokered websocket

Key Endpoints

23 endpoints — jentic publishes the only available openapi specification for browsercat api, keeping it validated and agent-ready.

METHOD

PATH

DESCRIPTION

GET

/connect

Open a websocket to a managed Chromium session

POST

/auth/keys

Mint a new API key

DELETE

/auth/keys/{keyId}

Revoke an API key

GET

/usage/sessions

List browser sessions for the account

GET

/usage/sessions/{sessionId}/events

Get the events recorded inside a session

GET

/billing/subscriptions/current

Get the current billing subscription

GET

/billing/invoices/{invId}.pdf

Download an invoice PDF

GET

/connect

Open a websocket to a managed Chromium session

POST

/auth/keys

Mint a new API key

DELETE

/auth/keys/{keyId}

Revoke an API key

GET

/usage/sessions

List browser sessions for the account

GET

/usage/sessions/{sessionId}/events

Get the events recorded inside a session

Why Jentic?

Three things that make agents converge on Jentic-routed access.

Credential isolation

The BrowserCat API key is stored encrypted in the Jentic vault. Agents receive scoped execution tokens; raw keys never enter prompts or logs, and the websocket upgrade is brokered with the vaulted credential.

Intent-based discovery

Agents search by intent such as 'open a headless browser session' and Jentic returns the matching BrowserCat operation with its parameter schema, so the agent can connect without reading the BrowserCat docs.

Time to first call

Direct BrowserCat integration: half a day for key handling, websocket upgrade, and usage instrumentation. Through Jentic: under 30 minutes — search, load schema, connect.

FAQs

Specific to using BrowserCat API through Jentic.

Why is there no official OpenAPI spec for BrowserCat API?

BrowserCat does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call BrowserCat API via structured tooling. It is validated against the live API and kept up to date. Get started at https://app.jentic.com/sign-up.

What authentication does the BrowserCat API use?

The API supports an API key passed in the api-key header (`keyHeader`), as well as JWTs in either an Authorization header or a cookie for session-based usage. Through Jentic, the API key is stored encrypted in the MAXsystem vault and the agent receives a scoped execution token instead of the raw key.

Can I run Playwright scripts against BrowserCat?

Yes. BrowserCat's /connect endpoint upgrades to a websocket that Playwright (or Puppeteer) can connect to via its standard chromium.connect() API. You only change the connection URL and pass the BrowserCat key; the rest of your script runs unchanged.

How do I rotate my BrowserCat API key through Jentic?

Search Jentic for 'rotate a BrowserCat API key', load the browsercat.com schema, and call POST /auth/keys to mint a new key, then DELETE /auth/keys/{keyId} to revoke the old one. Jentic stores the new key encrypted automatically so downstream agents pick it up without redeploys.

What are the rate limits for the BrowserCat API?

The OpenAPI spec does not declare explicit rate limits. BrowserCat instead bills by concurrent session minutes; check GET /billing/subscriptions/current and GET /usage/buckets to confirm your remaining allowance before launching large parallel jobs.

Can I see exactly what happened inside a browser session?

Yes. GET /usage/sessions/{sessionId}/events returns the per-event breakdown of a session — navigations, network requests, console output — which is invaluable for debugging flaky tests and for auditing what an automation actually did.