1. Create a set with a clear name and optional description and safe slug.
2. Supply template items using record_type, name_template, content_template and the applicable TTL, priority, order and protection fields.
3. Read the saved set and its returned version.
4. For edits, send the current version. Omitted items are retained, while a supplied items array replaces the entire template.
5. To deliberately clear a non-empty template, send the empty array with confirm_clear: true. Do not use it as an add-one-record shortcut.

This helper projects stored items and an add count, capped at 250 items. It is not a complete collision-aware provider diff and does not perform the portal's full variable interpolation. The variables field in the response is not proof that every template value has been expanded.

Use one for resolved variables, templates beyond the helper's projection bound, or record types needing fields that the simple helper does not carry into its generated copy. In this build that copy uses name, type, content and TTL, so verify priority-dependent MX or SRV data through an explicit complete record payload or the supported portal workflow.

The apply helper returns a changeset and queued work. Track that returned workflow rather than submitting a duplicate copy. Saving a template alone does not apply it to existing zones, and marking it as default is not an instruction to overwrite every customer's current records.

Use the current OpenAPI contract and the resulting record data as the reference for your integration. Retain a before-state snapshot when applying any reusable template to an established zone.

• Build and validate a reviewable DNS changeset
• Create and apply reusable DNS record sets
• Create DNS record sets that become package defaults
• Use the live Domain Nexus OpenAPI contract for your integration
• Create or change an authorised PTR record through the API