A changeset records the exact DNS edits you intend to make so they can be validated and reviewed before publication. Start from a current zone and record read. For an existing record, retain its returned record_key rather than calculating a new identifier from the replacement content.
IN THIS ARTICLE
01 Build the draft
| Method | Resource | Scope | Idempotency-Key |
|---|---|---|---|
GET |
/v2/dns/zones/{zoneId}/records |
dns:read |
Not required by this route |
POST |
/v2/dns/zones/{zoneId}/changesets |
dns:write |
Required |
POST |
/v2/dns/changesets/{changesetId}/validate |
dns:write |
Required |
PATCH |
/v2/dns/changesets/{changesetId} |
dns:write |
Required |
- Read the zone version and the complete required record collection, following pagination.
- Prepare a non-empty
operationslist usingadd,update,deleteorreplace. Each new value uses arecordobject;afteris an accepted alternative. - Include
base_row_versionfrom the reviewed zone and a meaningfulsummary. Describe destructive work accurately. - POST the draft with an idempotency key and retain both the submitted items and returned changeset ID.
- Call validate while the changeset is still a draft. Review any record errors before moving to approval and application.
A small add operation can look like:
{
"base_row_version": 7,
"summary": "Verify DNS integration on an owned test zone",
"operations": [
{
"operation": "add",
"record": {
"name": "_dn-test",
"type": "TXT",
"content": "integration-check",
"ttl": 300
}
}
]
}
The sample version 7 is illustrative. Replace it with the row_version returned for the zone you just reviewed, so the changeset records that reviewed state. Do not hard-code the sample version for later requests.
Can I patch the draft's record items afterward?
The current changeset PATCH changes its summary only. If the intended records change, create a newly reviewed draft instead of assuming an items field will replace the stored operations.
Does validation guarantee successful publication?
No. Record validation is one stage. Provider support, ownership, locks, current-zone conflicts and required approval remain relevant at application time. More than 25 items defaults to requiring approval; other protections can also apply.
For deletes and replacements, keep the before-state evidence and review record ownership carefully. A request containing a valid record identifier can still be wrong for the business task. Preserve unrelated mail, service verification and protected records unless their removal is explicitly intended.