Begin the cloud browser sign in for a connection

Customer present only. For a DNS provider with no sign in of its own, the customer signs in to the provider inside a temporary browser that a browser hosting company runs for a few minutes. They type their own username, password and any verification code into the provider's real sign in page, so CustomDomain™ never receives them, and nothing is stored. Our software then reads the provider's DNS page for this one domain, shows the customer the exact changes, and makes them only after the customer approves. It never creates an API key at the provider, and a session never runs without the customer present.

Returns the address of the popup page that shows the browser. Its fragment carries a single use bootstrap code, which no server sees; the popup trades it at POST /browser-sessions:redeem. Only an end user's widget token (bound to the domain and to the end user) or the console may start one: an agent, the MCP server and a plain API key are refused with browser_customer_present_only. The request must carry an Origin header on the server's return origin allowlist. A browser sends one (the widget and the popup do), and the console's server must add it to the call it makes for a customer. A request with no Origin at all, such as a server to server call, is refused with browser_customer_present_only and a message that says the header is missing; an Origin that is not on the list is refused the same way.

A record set an integrator supplied, and any type or value the provider's page cannot write, is refused before the customer signs in (browser_unsupported_records, with the types named). The rail is offered only for a provider that has no sign in of its own, and only while the deployment has it on (rails.cloud_browser on the domain check).