Use the module’s automation API for DNS integrations without distributing the broad upstream PowerDNS server key. This is an administrative integration credential, not a customer’s portal sign-in.

Create the intended token

1. Open PowerDNS → Maintenance → API access.
2. Name the integration and choose the smallest required read and/or write scopes.
3. Restrict source addresses where the caller has stable permitted addresses.
4. Create the token and save the once-shown value in private credential storage.
5. Copy the endpoint URL displayed for this installation.

Use the displayed endpoint rather than a URL copied from another billing platform. If a token is lost, revoke it and create a replacement; the original full value cannot be shown again.

Read before writing

Authenticate with the documented bearer header, or the supported alternative token header if your server strips Authorization. Start with zone and record reads. Obtain current record identifiers from a fresh response before an edit or delete.

Write requests remain subject to the module’s supported safety checks, including locks, content policies and managed-record protection. A read-only scope should not be widened simply to hide a wrong endpoint or source-address refusal.

Check results and rotate deliberately

Keep authentication failures, permission refusals, missing resources and rate limits distinct. Reconcile current record state after a timeout before repeating a write. Review Activity for the intended change and verify actual DNS independently.

For a working module token, create the replacement, update the intended integration and verify it before revoking the old token. This overlap is different from the upstream static-key rotation described in the server-key guide. Never include either token or server key in support attachments.

Account for native record-set scope

API record writes use the same PowerDNS record-set behaviour as the module editor: values sharing a name/type share a TTL. The module reads enabled members of recognised types, and writes can remove disabled native members in the affected set. If your deployment relies on disabled records, have your PowerDNS administrator preserve/review the native set before automation writes. Module snapshots and BIND exports do not preserve disabled members.

Check the API request and result

Your hosting team should compare the integration’s displayed endpoint, request method, token scope and permitted source address with the exact response. Keep authentication, scope, rate limits, missing records, zone locks and content-policy refusals separate. After a timeout, read current records and Activity before repeating a write. Wider scope is not a repair for a wrong endpoint or uncertain write.

See the PD PowerDNS Blesta guide for related tasks, or explore PD PowerDNS.