Concepts: the ideas behind the API
The ideas the Browserberg API is built on: session lifecycle, the three verbs, consent handling, isolation, versioning, provenance and plans.
How to read this section
These seven pages explain the model the API assumes — read them once and the reference pages stop needing footnotes. Start with the session lifecycle and the three verbs; everything else builds on those two.
All pages in this section
-
1
Session lifecycle: states, deadlines and billing
How a session moves from pending to released, when the billing clock starts, and why a deadline and an idle timeout are two different numbers.
-
2
The three verbs: observe, act, extract
Every Browserberg interaction is one of three verbs. What each verb does, which safety controls run on every act, and why refusals are content.
-
3
Consent autopilot: cookie banners handled
Cookie banners block automation on nearly every EU page. How the consent option clears them across roughly 17 CMP platforms, and why reject is the default.
-
4
Isolation and sovereignty by architecture
Where the trust boundaries sit in Browserberg: what runs natively, what runs in hardened containers, and how EU sovereignty is enforced in the request path.
-
5
Protocol versioning and compatibility
How clients and servers negotiate the Browserberg protocol: majors exact, minors ordered, strict requests, loose responses and open output enums.
-
6
Provenance and routing tiers
Every verb response carries a provenance block. What each field means, how to spot a cached replay that made no model call, and what tier tells you.
-
7
Plans, entitlements and metering
What the four Browserberg plans gate, how browser-hours are metered from readyAt to teardown, and how holdings are sampled once a day instead.