1. Read the changeset and compare it with the exact items your application submitted and the zone state reviewed during validation.
2. Confirm its current state is validated before using the approval endpoint. The caller needs dns:approve in addition to any ordinary write access.
3. Obtain the required business review for the affected records, especially a broad replacement or deletion.
4. POST approval with its own idempotency key, then inspect the returned state.
5. POST apply through the authorised write workflow. Store the returned task or job reference.
6. Poll the relevant changeset and task resources with a reasonable interval. Re-read the provider-backed record collection after completion.

Separate the job state, provider readback, authoritative answer and recursive cache. A completed provider write can coexist with an older cached answer until its TTL expires. A wrong delegation, failed target or signing error instead requires a concrete correction.

This endpoint requires the permitted current state and does not replace validation. If the request is rejected, inspect the existing changeset state rather than creating a parallel sequence of approval calls.

Use the original request identity and inspect the existing task. Do not create a new copy of the same changeset merely to get a visible success message. The provider may already have applied all or part of the intended work, so current-state reconciliation matters before retrying.

For a multi-server package, inspect each target's verification evidence. One finished task or one authoritative answer should not be used to claim every replica is consistent. Preserve the final changeset and request references with the customer's change record.

• Build and validate a reviewable DNS changeset
• Track DNS jobs without mistaking a queued task for a published answer
• Investigate DNS drift and request a fresh provider reconciliation
• Check DNS propagation and find the source of an old answer