A permission error invites another click. In my work, deployment, DNS changes and third-party ownership verification often looked like one problem even though they crossed different authorization boundaries.

The shared credential instructions preserved a history of an expired token and another authentication path. The October preview deployment used a separate management credential successfully. A past login method was not evidence that the same operation would work today.

Why I define the permission before the edit

I want an operator to have enough access to fix my site without changing unrelated sites. I record the goal and allowed scope first, then verify success inside that boundary.

One login does not prove every permission

Browser sign-in, an API token and the selected account are separate checks. Read access does not prove permission to edit DNS or deploy Pages. Compare the requested operation against the documented permission and resource scope.

The diagnostic order I use

  1. Name the failed operation: read, deployment, DNS edit or ownership verification.
  2. Record response and error codes without credentials or authorization headers.
  3. Use a read-only request to confirm the account and target project.
  4. Check credential status, required permissions and the allowed resources.
  5. Keep the successful and failing paths separate. Retry after narrowing the cause.

Publish the procedure, not the secret

An operation, resource type, error code and verification date are useful knowledge. A real token, cookie or private account identifier is not needed to teach the method. Examples should name credential variables without filling them.

A token verification result also does not establish write permission for every project. Making a credential broader is not a substitute for understanding the missing authorization.

Explore the implementation

PowerShell example that does not print the token

$cfHeaders = @{ Authorization = 'Bearer ' + $env:CLOUDFLARE_API_TOKEN }
$check = Invoke-RestMethod -Uri ($cfApiBase + '/user/tokens/verify') -Headers $cfHeaders
$check.result.status

What establishes completion

The originally failing action succeeds on the intended resource, and its result is read back. Separating authentication success from functional success makes the record reusable.