Installation: SDKs and the raw HTTP surface
Install the TypeScript or Python SDK or call the HTTP API directly, and learn what the protocol version header negotiates for you.
Last updated:
Three surfaces, one API
Browserberg exposes one HTTP API and three ways to hold it: the TypeScript SDK, the Python SDK, and the raw endpoints. Pick per team, not per project — the wire format is identical underneath, so a workflow published from Python is inspectable from TypeScript or plain cURL without translation.
The SDKs are thin on purpose. They add session handles that release themselves, schema conversion for extraction, and typed responses; they do not add behaviour the API lacks. Anything these docs show in an SDK tab can be reproduced with two or three curl calls.
Install an SDK
One package per language, no peer dependencies, no CLI to set up.
npm install @browserberg/sdkpip install browserbergNote · Not on the registries yet
The packages are not yet published to npm or PyPI. The commands above show the intended install path; today you install both SDKs from the repository checkout.
Requirements and version negotiation
You need Node 18 or newer for the TypeScript SDK and Python 3.10 or newer for the Python one. Both re-export the complete protocol vocabulary — every request and response type, every enum — so there is no second types dependency to keep in sync.
Each request may carry an x-browserberg-protocol header. Negotiation is deliberately narrow: major versions must match exactly, and the server minor must be at least the client minor. In practice that means an older SDK keeps working against a newer server, and a response may contain fields your version never asked for — the SDKs tolerate them, and your code should too. A request with a misspelled field, on the other hand, is refused with a 400 rather than silently ignored.