Replace a Cloudflare API token used by WordPress

Identify the integration and the secret to replace

A WordPress plugin may use a Cloudflare token to read a zone, purge its cache, or manage certain options. A deployment script may also have its own token for a similar operation. During a handover, rotation must let you identify which consumer uses the access and remove only that access after validating its replacement. A Cloudflare logo in WordPress is not enough to identify the authentication mechanism.

Record the plugin and its version, the functions used, the Cloudflare account, and the relevant zone. Ask the maintainer whether the secret is a user token, an account token, or an old global key. The screens and replacement options differ. This procedure covers an API token that the integration allows you to replace. If the component uses another method, check its documentation before supplying a token in a field intended for a global key.

Record the reason for the change. A planned rotation allows you to prepare a brief overlap between two tokens. For exposed access or a compromised account, the security owner may require immediate removal and a controlled interruption of dependent operations.

Map the token to all its consumers

In the WordPress configuration, record the secret reference and the account or zone displayed. If the value comes from an environment variable or a vault, identify the source that publishes it. Ask which other services read this same reference. A token may have been shared between a plugin, a staging environment, and a pipeline that purges the cache after every release. Changing the value in wp-admin does not necessarily update the other consumers.

For each consumer, record the service name, the Cloudflare function used, the execution context, and how to check the loaded version. An infrequent task may still depend on the token even if no errors appear on the site for a day. Check maintenance scripts and manual operations included in the handover. A vault reference and a token identifier are enough to match the records, without copying the value into the table.

Also confirm who owns the token and who owns the Cloudflare account. If a contractor is leaving the organization, the replacement person must have permission to create and manage access under the account model. Account continuity and token replacement must be checked before removing the contractor.

Record the required operations and resources

List the functions the integration actually uses. Purging a cache and modifying DNS require different permissions. The WordPress template documented by Cloudflare prepopulates several permissions and a resource scope. Review these values and compare them with the needs of the plugin version. A template is a starting point. Its WordPress name does not justify applying it without checking the included accounts and zones.

The official plugin has a documented workflow using a token created from the WordPress template. If you then restrict its resources, validate the functions used in that environment. A third-party plugin may require a different set. Also record source address and date restrictions that may limit a token’s validity. A staging server or worker may use a different outbound address from the public frontend.

Keep a record of the approved permissions, resources, and conditions before making changes. These details help interpret a refusal after replacement. Avoid adding DNS write permission just to fix a zone read refusal or an account selection error.

Create a replacement token in the correct area

For a user token, the documented workflow starts at My Profile, then API Tokens, in the Cloudflare dashboard. For an account token, creation takes place under Manage Account, then API Tokens, and requires compatibility with the endpoints used. Use the type expected by the integration and the authorized role. Create a new token with a name that identifies the function, environment, and service owner.

Choose the approved template or custom configuration, then check the included resources before confirming. For an integration restricted to one zone, check the zone name and identifier and its parent account. Review any start, end, and source address conditions you use. An overly narrow restriction can prevent a legitimate process from connecting from its actual origin.

Save the new value directly in the designated vault and record the entry identifier. The maintenance record should keep this reference, the date, and the permissions rather than the secret. Keep the old token active for the period specified in the plan, only if doing so remains acceptable. This lets you test the new token before removing the old one.

Prepare the switch in WordPress and external processes

Back up the integration settings according to its procedure. For a configuration stored in the database, the backup may contain a secret and must be protected accordingly. For a deployment, keep the reference to the previous version and a way to restore a valid configuration. Check that the replacement person can access the vault and deployment channel without using the personal account that is due to leave.

On an isolated copy or within an approved scope, replace the token in the plugin’s designated field. Menus vary by component. Use its documentation and confirm the account and zone it recognizes after saving. For a service that reads the value at startup, apply its usual renewal mechanism. Record the version loaded on each server group and on independent tasks.

Avoid changing SSL mode, DNS, cache rules, and the secret at the same time. The test must allow you to attribute the result to the access replacement. However, a purge can have an operational effect. Choose a demonstration resource and the least disruptive verification mechanism compatible with the need.

For the official Cloudflare plugin, the documented workflow goes through Plugins, the Cloudflare entry, and then Settings. The screen for connecting an existing account asks for the email address and token, which are saved with Save API Credentials. If a connection already exists, record its state and use the replacement workflow provided by that version; do not reinstall the plugin to change a secret. The getting-started page then continues to Apply Recommended Settings and enabling APO: these operations change the service configuration and are not part of a simple rotation. The documented APO workflow does not cover WordPress multisite; check the product and integration mode actually in use before applying its screens to your setup.

Verify authentication, then an authorized operation

The token verification endpoint may indicate that a token is active. This response confirms one aspect of its validity, but zone or operation permissions need a specific check. If the plugin offers a connection test, record what it actually checks and the selected zone. A recognized account does not prove that a purge or a statistics read is authorized on the intended resource.

For a purge integration, use an agreed demonstration page and trigger the component’s intended targeted action. Match the result against its log and, where access allows, the operation on the Cloudflare side. Check the resource concerned and the response received. Avoid a global purge to test a single permission. The visual result of a page alone may be ambiguous when several caches are involved.

For a read integration, request an expected test value or a limited inventory in the correct account. Record the status, time, and configuration version. Do not display the token in a shared terminal. Command examples that insert a secret in plain text can leave traces in history, logs, or support tools.

Diagnose a refusal without expanding permissions

If the test fails before any operation, check the expected authentication type. An API token uses the scheme specified by its integration. An old account address and global key pair is not interchangeable with it. Then check the saved value and the time or network conditions. A truncated value or a future start date can explain an immediate refusal. Keep only a redacted message.

If the connection succeeds but a function fails, compare the requested permission and targeted resource with the approved state. A token valid for one zone may be refused on another zone in the same account. An origin restriction may also allow the frontend through while blocking a worker. Ask the owner to confirm that process’s outbound address before changing the rule.

If you receive an HTML page or a response from an intermediary, check the network route and API address with the operator. Adding token permissions does not fix an incorrect destination. Restore the healthy configuration if the rollback plan calls for it, then have the identified cause resolved before switching again.

Remove the old token after replacing it for every consumer

In the area that manages the token, identify the entry by its name, identifier, and owner. Check that the consumer table is complete and that every service has loaded the new reference. Then use the dashboard’s removal action. If management is automated, ask the mechanism’s owner to apply the documented operation for that token type and confirm its identifier and the time.

After removal, perform another authorized operation with the replacement. For deferred tasks, check the next normal run. If the plan allows a negative check of the old token, use the designated secure client and an endpoint without a business effect. Avoid copying a removed secret into a new tool just to produce this evidence. Confirmation of removal by the manager and a working replacement may be the available evidence.

Removing a token does not automatically delete zone settings it was used to create. If rules or records also need to be removed, have them reviewed separately. Replacing access must not become an implicit deletion of configuration the site uses.

Plan rollback before and after revocation

Before removal, the old configuration can be restored if the token remains valid and uncompromised. Restore the previous reference in the affected consumers, then check a new operation. A secret restored in the database may still be unusable if its conditions have changed on the Cloudflare side. Check both levels. A rotation carried out during an incident must not reintroduce a compromised value as a fallback.

After removal, prepare a new token for any forgotten consumer. Review its needs and test its permissions within the approved scope. Avoid restoring the entire WordPress database to recover an old connection setting. That could affect recent writes and would not make a token valid with the provider. A targeted correction of the secret and its configuration is generally the first option to examine.

If a task stopped during the switch, identify its last successful batch before resuming it. A missed purge, a synchronization, and a DNS change have different consequences. The process owner must determine whether a rerun is useful and what effects it may have on the zone.

Check a handover involving several zones

For an agency managing two stores, prepare a record for each zone and integration. A legacy token may have covered all zones even though each store uses only one domain. A replacement restricted to each store makes permissions and incidents easier to attribute. First validate that the plugin and its functions actually use that scope. Some account functions may require an additional resource, to be confirmed in the relevant documentation.

If staging must be isolated, give it a separate reference and check its permissions on the test resources. A database copy may reintroduce the production secret during the next clone. Have that value removed by the copy template or environment configuration before its first run. Add this check to the acceptance process for a new staging environment.

Record who is responsible for renewing and deleting each token. A user token may depend on a person whose permissions change. An account token follows a different model. A decision to change type requires checking the compatibility of the integration and service, including the endpoints actually used.

Close out the replacement with evidence of scope

The final record should associate each consumer with its token type, account, zones, permissions, and vault reference. Add the authentication result, the operation actually tested, and the time the old access was removed. If a function could not be exercised, leave its check assigned to its owner. Success on one zone does not validate other zones or a different write function.

The token mechanism and a plugin’s functions depend on Cloudflare access and the contract, as well as the chosen WordPress component. The presence of a WordPress template does not prove that a commercial option is included in the site’s plan. Check the limits and pricing of the option actually used with its publisher. The replacement procedure requires no purchase as long as the functions and permissions already exist.

Keep the record in the authorized maintenance area. The next review should be able to find the secret’s owner and check its scope without discovering its value in a screenshot or command history.

The WordPress Workshop.

Validate a user token without putting it in a command

For a user API token, Cloudflare provides a verification command in its creation workflow. A maintainer can also use this small local Python 3 script: it prompts for the secret without displaying it and prints neither the token nor the full response. Run it in a private terminal without session recording. It is not suitable for the verification endpoint specific to account tokens.

An active result does not validate access to your zone. For a read integration, then check the designated zone with the required read permission; for a purge, test a demonstration URL with the purge permissions expected by the component. These permissions are not interchangeable. Revoke the old token only after replacing it for the listed consumers. The script does not modify any zone and does not justify buying APO; it checks only this authentication endpoint.

import getpass
import json
import urllib.error
import urllib.request

token = getpass.getpass("Jeton API utilisateur : ")
request = urllib.request.Request(
    "https://api.cloudflare.com/client/v4/user/tokens/verify",
    headers={"Authorization": "Bearer " + token},
)
try:
    with urllib.request.urlopen(request, timeout=15) as response:
        data = json.load(response)
    if not isinstance(data, dict):
        raise ValueError("Reponse inattendue")
    result = data.get("result")
    print("Requete acceptee :", data.get("success") is True)
    print("Etat :", result.get("status", "non indique") if isinstance(result, dict) else "non indique")
except urllib.error.HTTPError as error:
    print("Refus HTTP :", error.code)
except (urllib.error.URLError, TimeoutError, ValueError):
    print("Verification non concluante : transport ou reponse non lisible")
finally:
    token = None