Begin the sign-in to the DNS provider for a connection

Server URLloading...

POST

/connections/{id}/oauth:start

Send

Authorization

Path

Body

Rail C (flagship). Returns the URL the widget opens in a popup, bound to an HMAC-signed single-use state. The provider redirects back to /v1/connect/oauth/callback, which writes the connection's records with what the provider handed over. flow says which sign-in runs: oauth2 (authorization code with PKCE S256; for Google Cloud DNS, Sign in with Google Cloud, whose callback first finds the Google Cloud project that holds the domain's public zone; for Azure DNS, a Microsoft sign-in whose callback first finds the Azure subscription and resource group that hold it), vercel_integration (the CustomDomain™ integration's install page; the user picks the Vercel team that owns the domain), porkbun_handoff (Porkbun's PKCE API key handoff: the user approves a key named after the domain; no client registration is needed), porkbun_dnsconnect (Porkbun's DNS Connect, run in place of the handoff for a connect when the deployment holds an application Porkbun approved, OAUTH_PORKBUN_CLIENT_ID and OAUTH_PORKBUN_CLIENT_SECRET: the domain's records are signed into the request, the user approves them at Porkbun, and Porkbun adds them itself, with no API access switch needed; nothing comes back, so managed is always false, and signing in to remove the domain still runs the handoff), ovh_consent (an OVHcloud consumer key limited to the domain's DNS zone, validated on OVHcloud's page for the chosen region) or mcp_oauth (OAuth through the provider's hosted MCP server, for Hostinger, Unstoppable Domains, XServer, Namecheap, Spaceship and Dynadot: the endpoints are discovered from the server's metadata, the client is one the control plane registered for itself, and the records are written through the server's DNS tools; offered only for the providers the deployment lists in MCP_SIGNIN_PROVIDERS). The credential is used for that write and dropped, unless the deployment keeps grants for this provider (OAUTH_MANAGED_PROVIDERS with GRANT_ENCRYPTION_KEY), in which case managed is true and it is stored encrypted for :reapply.

A widget JWT starts the sign-in for its own application's connections (a domain-bound token for its own domain only); an API key for a connection of any application in its tenant, and a member's key needs a role that operates apps.

A widget token must be the connection's end user: a connection that names another end user than the token's end_user_ref, or names one while the token names none, answers 403 token_wrong_end_user before anything is read or changed, and a connection that names none is any token's. An API key, an app-scoped token and a delegated agent token are not limited by it.

Signing in to remove the domain (purpose: remove) keeps its own answer, 403 forbidden, for a token that is not the end user's, and for a share link's token on every connection: a link sets a domain up and never removes it.

Path Parameters

Response Body

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

{  "authorize_url": "http://example.com",  "provider": "string",  "flow": "oauth2",  "managed": true,  "access": "continuous",  "purpose": "remove",  "callback_origin": "string",  "region": "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"}

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

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

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