Page reports API reference

Five endpoints on a live session answer structural questions about a page without ever calling a model: which consent platform is showing and what the browser held before any choice, what the agent's tree looks like, where every control leads, whether a cancellation control is reachable, and a picture of the page. All five are POSTs against a session id carrying your bb_ key as a bearer token, and all five are computed from the same perception the agent runs on — which is why they still work on a deployment that has sessions and no inference gateway at all.

They arrived in protocol 1.5. A client that announces x-browserberg-protocol: 1.5.0 to an older server is refused with protocol_incompatible rather than discovering the gap route by route. A deployment that offers them lists reports in the features array of GET /v1/me; one that does not never registers the routes, so a call gets not_found.

Three failures are worth branching on. A body that fails validation is invalid_request (400) with the first ten schema issues in details.issues. A session that does not exist, or belongs to another organisation, is not_found (404) — the same answer for both, deliberately. A URL the browser refuses to open, for DNS, TLS or a blocked scheme, is navigation_failed (422). A page that simply never finishes loading is not a failure at all: after fifteen seconds the report is taken as the page stands and a line is added to warnings.

A cookie row is {name, domain, path, expiresAt, secure, httpOnly, sameSite?, thirdParty}. expiresAt is ISO 8601, or null for a session cookie, and thirdParty compares the cookie's registrable site with the page's. A host row is {site, requests, thirdParty}, where site is the registrable site (eTLD+1), so cdn.example.com and example.com fold into one row with one count; rows are sorted by request count, busiest first.

The request collector is attached before the navigation, not after it, which is the only reason the third parties a page fires on load appear at all. Cookies are read through Network.getAllCookies and, where a newer Chromium has retired it, Storage.getCookies; if neither answers you get an empty list and a warning saying so, never a guess. newCookiesAfterReject counts the cookies present after the reject that were absent before it, keyed on domain, path and name together.

jsClickable marks an element that has no interactive role of its own and is clickable only because a script listens on it — common on portals built out of styled divs. hasAccessibleName is false for a control neither an agent nor a screen reader can address by name, which is usually the single most useful number on the page: an interactive surface where half the buttons are nameless is one an agent will struggle with for reasons that have nothing to do with the model.

The rendered text is page content. Treat it as untrusted and fence it before it enters another prompt, exactly as you would the tree that comes back from observe.

action is what an agent would do with the element — click, type, select or scroll — decided from its role and tag, never from an instruction. destination is {url, via, method?, target?, hasFileInput?, unresolved?}, and via records how the target was found: href, ancestor-href, formaction, form, implicit-submit, script when only code knows where it goes, or none when nothing was found at all.

risk is the destination guard's finding for that one control, judged on its own. The guard normally stops at the first blocked step of a plan, which is right for a plan and wrong for a census, so each control is run through it separately. off_site_submit, insecure_submit and unsafe_scheme are refused under the default policy and set blockedUnderDefault; off_site_navigation is permitted by default — an SSO redirect leaves the site legitimately — and sets only blockedUnderStrict. A script-scheme href is not a risk at all: legacy portals write one on every grid link, so the guard leaves it alone and the report says only what it saw.

The candidate that gets followed is the first one whose destination has a URL and does not lead to another registrable site. A candidate whose target only a script knows cannot be followed without pressing it, and pressing a cancellation unattended is exactly what the product refuses to do — so it is skipped and a warning says why. followed is therefore null in four different situations: no candidate was found, follow was false, every candidate led off-site or was script-only, or opening the target failed.

When a page was followed, confirmationControls lists the buttons and links on it whose label reads like the confirming press — the cancellation vocabulary again, plus the ordinary confirm and submit words in German and English. fields lists what the page asks for as {role, name, required}, where required is null when the page said nothing either way. That is the interesting half for a consumer question: a cancellation reachable in one click that then demands a customer number is a different experience from one that does not.