CustomDomain Docs
Connections

Re-apply a managed connection's desired records (async one-click, no re-consent)

reapply connection: reference page for this CustomDomain™ API operation in the connections group. Covers parameters, request body, responses and error codes.

POST
/connections/{id}:reapply

Managed mode only. Recomputes the connection's authoritative desired record set and writes any drift through the provider's async one-click API using the stored, encrypted grant (the provider API base pinned at onboarding), or, for a connection managed through a provider sign-in, through the provider's DNS API with the kept credential (a refresh token is rotated first when the access token has expired); the end user does not re-consent. On success the connection is re-verified and connection.records.updated is emitted. A failure emits connection.reapply.failed; if the provider reports the grant was revoked (401 kill-switch, or a refused refresh token) the grant is cleared and the connection is flagged for re-consent (a sign-in grant leaves error_code oauth_reconnect_needed).

A domain kept by a continuous provider account (and no kept grant) is re-applied with the account's key: the records CustomDomain™ wrote for the domain are written back and the receipt says via: provider_account. A domain whose records CustomDomain™ did not write is refused with 409, since re-applying would write records nobody put there. The same webhooks are sent.

A delegated agent token needs domains:connect. Each of its calls that reached a write (the account's, the kept grant's or CustomDomain™'s own zone's), whatever the answer, is recorded as agent.acted ("re-applied a domain's records") for the grant, since a provider that refuses can have changed some record sets; one refused before anything was sent (nothing applied for the domain, a domain not managed or being removed, a rail or an account that is unavailable) leaves no row.

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 written, and a connection that names none is the token's as before. An API key, an app-scoped token and a delegated agent token are not limited by it.

Authorization

AuthorizationBearer <token>

Short-lived widget JWT minted server-side via POST /v1/tokens. Scoped to one application (and optionally one domain).

In: header

Path Parameters

id*string

Response Body

application/json

application/json

application/json

application/json

application/json

application/json

curl -X POST "https://example.com/connections/string:reapply"
{  "connection_id": "string",  "reapplied": true,  "via": "provider_account",  "records": [    {      "type": "CNAME",      "host": "string",      "value": "string",      "ttl": 3600,      "priority": 0,      "applied": true,      "change": "created",      "prior": [        {          "type": "string",          "value": "string",          "ttl": 0,          "priority": 0        }      ],      "prior_source": "provider"    }  ]}
{  "code": "string",  "title": "string",  "details": "string"}
{  "code": "string",  "title": "string",  "details": "string"}
{  "code": "string",  "title": "string",  "details": "string"}
{  "code": "string",  "title": "string",  "details": "string"}
Empty
Empty
{  "code": "string",  "title": "string",  "details": "string"}