Create a scoped module API token for a backend integration that needs to read or change Route 53 records. It is separate from the AWS access-key pair, the PD licence connection and a customer’s client-area login.

Prepare the integration

1. Open AWS Route 53 DNS → Maintenance → API access.
2. Give the token a recognisable integration name.
3. Choose read or write scope according to the intended operation.
4. Restrict caller source IPs when the integration has a fixed outbound address.
5. Store the one-time token privately and copy this installation’s endpoint from the panel.

Do not expose an administrative token in browser JavaScript or treat it as a credential restricted to one customer. Use a separate token per integration so attribution, rotation and revocation remain clear.

Authenticate and read first

Use HTTPS with Authorization: Bearer authentication. The documented X-Api-Token header is an alternative if the server strips the standard header. Keep tokens out of public logs and support screenshots.

Use GET with action=zones to list tracked zones and action=records with the selected zone for live record data. Confirm the intended zone, record name and type before preparing a write. The zone list is capped at 1,000 tracked entries, so an absent row is not proof that AWS has no such zone. This API resolves the requested domain to its first tracked match; it does not offer a provider or hosted-zone-ID selector. If that domain is tracked under more than one provider, establish the intended mapping with your hosting team before using API writes. Read/write scopes do not restrict a token to one customer or zone.

Write and reconcile

Use POST with addrecord, editrecord or delrecord. An edit/delete uses recid from the live records result; deletion also confirms the intended type and name. Supply priority, weight and port where the record type needs them.

Read back the resulting record after a write. An uncertain response may follow a successful AWS change, so reconcile actual state before retrying. The API honours relevant locks, content policies and managed-record protection; it is not an escape from a refused customer edit.

Review 401, 403, 404 and 429 as different authentication/permission/target/rate-limit conditions, and back off when limited. Rotate by creating a replacement, switching the integration, verifying it and revoking the old token. Use Maintenance and Activity to investigate the original result.

Check same-named hosted zones before changes

If your AWS account contains multiple hosted zones with the same domain name, do not assume choosing a same-named row selects a particular hosted-zone ID. This module resolves zones by name. Have your AWS administrator compare the exact hosted-zone ID, records and delegated nameservers before using module writes; use AWS’s native zone-specific controls if the target remains ambiguous. Do not create or delete another zone to diagnose that ambiguity.

Check the request and record state

Your hosting team and integration developer should compare the copied endpoint, HTTP method, token scope, caller address, requested domain and redacted response. Check authentication, local tracked-zone selection and AWS permission failures separately. Read the current record set before retrying an uncertain write. Do not include the token, authentication headers or a full request containing customer verification values.

See the PD AWS Route 53 DNS Blesta guide for related tasks, or explore the module.