A scoped Cloudflare API token lets an integration manage only its required resources. For DNS automation, restrict the token to the relevant zone and required DNS operations rather than sharing a global account key.
IN THIS ARTICLE
Check access and requirements
Confirm the integration supports API tokens and identify whether it needs DNS editing, zone lookup or read-only access. Choose the correct Cloudflare user or account-token model supported by that integration.
01 Create a limited Cloudflare API token for DNS automation
- For a user token, open My Profile > API Tokens and choose Create Token. Account tokens are managed separately under the account’s API Tokens page.
- Start with the DNS-edit template or a custom token and give it a purpose-specific name.
- Limit permissions and zone resources to the actual task. Add only the read capability the integration needs to discover its zone, if required.
- Use a suitable expiry and source-IP restriction where stable automation makes that practical. Review the summary and create the token.
- Store the displayed secret in the integration’s protected secret store, test the required operation on the intended zone and record the owner and rotation date.
02 Example: scope a token to one DNS task
Suppose an integration needs to maintain DNS records only for example.com. Select that exact zone in the token resources, then compare the requested operations with the permission level. Do not use a global key to avoid deciding the scope.
| Integration task | Permission decision |
|---|---|
| Inventory existing DNS records | Use the applicable DNS Read permission for the selected zone. |
| Create or change records | Use the required DNS Edit permission for that zone. |
| Discover the zone through the API | Add the specific lookup permission only if the integration documentation requires it. |
Store the one-time secret in the integration's protected settings. Verify the intended operation with an approved test record where changes are needed, and confirm an unrelated zone is not accessible.
Expected result: the task works within the selected zone. An active-token check alone does not establish that the resource permissions are correct.
Confirm the expected result
The integration should perform its authorised DNS task and fail against unrelated zones or capabilities. Token verification confirms validity but does not prove every intended permission is correct.
Resolve setup problems
If authentication works but a record operation fails, inspect resource scope and the integration’s required permission names. Do not solve every error by granting all-zone access. Revoke and replace a token that appears in a repository, screenshot or public log.
Can I retrieve the full token secret later?
The secret is shown when created. Store it securely then; if it is lost, create a replacement and rotate the integration rather than assuming the dashboard can reveal it again.