Begin the cloud browser sign in for a connection

Server URLloading...

POST

/connections/{id}/browser:start

Send

Authorization

Path

Body

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 the sign in itself is never stored. Where the deployment turned it on for the provider, the agent then makes a lasting API key on the provider's own API page (named CustomDomain and the application's name, with the domain and DNS scopes only and the longest expiry the provider offers), checks it with one read only call, keeps it encrypted for this application only, and writes the records through the provider's API; the domain is then monitored and repaired like any connected provider account, and the connection's credential shows the key's record (never the key). Otherwise, or when making the key fails, our software reads the provider's DNS page for this one domain, shows the customer the exact changes, and makes them only after the customer approves. A session never runs without the customer present.

With mode: reconnect, the session is the end user's sign in that renews the connection's lasting API key (when it nears its end or the provider stopped accepting it): the agent makes a new key with the same scopes, checks it and swaps it in, and changes no DNS record. A connection without such a key is refused with browser_reconnect_unavailable. A reconnect link (POST /connections/{id}:reconnect-link) opens the hosted page in this mode.

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).

Path Parameters

Response Body

curl -X POST "https://example.com/connections/string/browser:start" \  -H "Content-Type: application/json" \  -d '{    "provider": "string",    "return_origin": "string",    "consent_version": "string"  }'

{  "session_id": "string",  "open_url": "http://example.com",  "vendor": "string",  "expires_at": "2019-08-24T14:15:22Z"}

{  "code": "string",  "title": "string",  "details": "string"}

{  "code": "string",  "title": "string",  "details": "string"}

{  "code": "string",  "title": "string",  "details": "string"}

{  "code": "string",  "title": "string",  "details": "string"}

{  "code": "string",  "title": "string",  "details": "string"}

{  "code": "string",  "title": "string",  "details": "string",  "types": [    "string"  ]}

{  "code": "string",  "title": "string",  "details": "string"}

{  "code": "string",  "title": "string",  "details": "string"}