Use the module’s API access tokens for backend integrations such as deployment tooling, monitoring or DNS validation. These administrative integration credentials are separate from both the DNS provider credential and a customer’s portal login.

Before a change, confirm the provider connection and the actual zone it resolves. With Route 53, name-based operations resolve the first matching hosted-zone name; selecting a familiar domain is not sufficient when AWS holds multiple zones with that name. Have your AWS administrator compare the hosted-zone ID, records and assigned nameservers before proceeding. With Google Cloud DNS, the current connection derives the managed-zone name from the domain. An existing zone with a different native name can appear in a list yet fail to open correctly; establish that mapping with your Google Cloud administrator instead of creating a duplicate zone.

For a PowerDNS backend, module reads and zone-file snapshots omit disabled native record values. Editing an affected record set can rebuild it from the enabled values. If your hosting team uses disabled records, preserve and review the native record set with your DNS administrator before module changes; use your established native management process where those values must be retained. A module export is not a complete backup of those disabled values or other provider settings.

Create the integration token

1. Open DNS → Maintenance → API access.
2. Give the integration a recognisable name and choose read or write scope as needed.
3. Restrict caller source IPs when the integration has a fixed outbound address.
4. Create the token and store its one-time value privately.
5. Copy this installation’s endpoint URL directly from the panel.

Do not substitute another platform’s endpoint or expose an administrative token in website JavaScript. Create one token per integration so permissions and revocation remain clear. Token creation does not make it a per-customer credential limited to one client’s zone.

Authenticate and read first

Use HTTPS and Authorization: Bearer authentication. The documented X-Api-Token header is an alternative when the server strips the standard header. Do not put the token in public logs or support screenshots.

Use GET with action=zones for tracked zones and action=records with the chosen zone for its live records. Establish the intended zone/name/type before preparing a write. The zones response is capped at 1,000 tracked entries. Record operations resolve the first tracked match for the requested DNS name without an explicit provider selector. If the same domain is tracked under several connections, establish the intended mapping before API writes; absence from one list response does not prove the provider has no such zone.

Submit and verify a change

Record writes use POST with addrecord, editrecord or delrecord. Edits and deletes use recid from the live records result; deletion also supplies the intended type and name. Include the extra priority, weight or port fields where the record type needs them.

Read back the affected record after a write. Reconcile a timeout before retrying because the provider may already have accepted it. The API honours zone locks, content rules and protected forwarding records; do not use it to bypass a refused client edit.

Review 401, 403, 404 and 429 as distinct authentication/permission/target/rate-limit conditions. Back off when rate limited. Rotate by creating the replacement, switching the integration, verifying it and revoking the old token. See Maintenance and Activity for results.

See the PD DNS Manager WHMCS guide for related tasks, or explore the module.