Supply the connection's desired DNS record set

Server URLloading...

PUT

/connections/{id}/records

Send

Authorization

Path

Body

Replaces the connection's desired record set with one the INTEGRATOR authored, for records that cannot be derived from the domain; the motivating case is Amazon SES email verification, whose three Easy-DKIM CNAMEs are minted per domain by SES. The supplied set then behaves exactly like ours: the OAuth rail writes it with the customer's provider credential, the widget renders it for manual setup, and the propagation poller verifies it before the connection goes live.

Server-to-server only (API key): a widget JWT lives in a browser and may not choose the records we write into a customer's zone. Hosts are relative to the connection (@, _dmarc, sel._domainkey) and must resolve inside its zone. The Domain Connect rail refuses a connection carrying a supplied set, because that rail applies OUR published templates at the provider, so it cannot write records it did not author.

Path Parameters

Response Body

curl -X PUT "https://example.com/connections/string/records" \  -H "Content-Type: application/json" \  -d '{    "records": [      {        "type": "CNAME",        "host": "string",        "value": "string"      }    ]  }'

{  "connection_id": "string",  "records_source": "integrator",  "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"}

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