Create a Cloudflare API Token for Workers with One Pre-Filled Link

Cloudflare's custom token screen has a long list of permission groups, and the wrong choice shows up later as a vague Authentication error [code: 10000] in the middle of a deploy. If you are setting a project up for someone who does not live in the dashboard, "go and tick the right boxes" is a bad instruction. There is a better way: a link that opens the token screen with everything already selected. The owner clicks three buttons and pastes the result. This is the link we used, what it grants, and how to use the token without logging in.

The link

The create-token page reads a few query parameters. The important one is permissionGroupKeys, a URL-encoded JSON list of permission keys and levels. This list deployed a Worker with static assets, a KV namespace, a Workflow, a Durable Object and the Workers AI binding:

[
  { "key": "workers_scripts",     "type": "edit" },
  { "key": "workers_kv_storage",  "type": "edit" },
  { "key": "d1",                  "type": "edit" },
  { "key": "account_settings",    "type": "read" }
]

A few lines of Python build the link:

import json, urllib.parse

perms = [
    {"key": "workers_scripts", "type": "edit"},
    {"key": "workers_kv_storage", "type": "edit"},
    {"key": "d1", "type": "edit"},               # drop this one if you do not use D1
    {"key": "account_settings", "type": "read"},
]
query = urllib.parse.urlencode(
    {"permissionGroupKeys": json.dumps(perms, separators=(",", ":")), "accountId": "*", "zoneId": "all", "name": "my-project"},
    quote_via=urllib.parse.quote,
)
print("https://dash.cloudflare.com/profile/api-tokens?" + query)

Open the printed link while logged in. The page shows the token with those permissions already chosen and a name filled in. The person clicks Continue to summary, then Create Token, and copies the value, which is shown only once.

One caution: we did not find this query format in Cloudflare's documentation. It worked in October 2026, and a page that is not documented can change. If the page opens without the permissions ticked, the fallback is the same four entries chosen by hand.

What each permission is for

• Workers Scripts: Edit uploads the Worker and its bindings. In our project it also covered the Workflow and the Durable Object migration, so no separate permission was needed for them.
• Workers KV Storage: Edit creates the namespace and attaches it to the Worker.
• D1: Edit is for projects with a D1 database. We did not use it and included it for later, so remove it if you want the smallest possible token.
• Account Settings: Read lets a script list the account, which is how it finds the account ID.

Nothing about zones or DNS is needed for a workers.dev deployment.

Use it headless

With the token in an environment variable, wrangler runs without a browser login:

export CLOUDFLARE_API_TOKEN="paste-the-token-here"
export CLOUDFLARE_ACCOUNT_ID="..."          # optional, see below
export WRANGLER_SEND_METRICS=false CI=1
npx wrangler deploy

You do not have to ask anyone for the account ID. The token can list the accounts it belongs to, and a script can take the first one:

curl -s https://api.cloudflare.com/client/v4/accounts?per_page=50 -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN"
# result[0].id is the account ID

The same token can also create the workers.dev subdomain on a fresh account (PUT /accounts/{id}/workers/subdomain) and the KV namespace (POST /accounts/{id}/storage/kv/namespaces), so a deploy script can set up a new account without any dashboard clicks. The deploy checks we use print which of these calls the token is allowed to make, so a missing permission is named instead of showing up as a generic error.

Treat the token like a password

• It is shown once. Store it in an environment variable or a secret manager, never in the repository.
• Give it a name that says what it is for, so you can recognize it in the token list later.
• Revoke it after launch if the Worker does not need it. Ours is only needed to deploy. The running Worker holds a single secret, an admin key, so we revoke the token when we are done and create a new one from the same link when we want to deploy again.
• The same token could also read the Workers AI usage through the GraphQL API, which is how we measured our daily neurons: see Check Your Workers AI Usage with the GraphQL Analytics API.

Why this matters

The most common reason a non-technical owner gets stuck on a Cloudflare project is the permission list. Replacing a page of instructions with one link, and a script that checks the result, removes the step where people give up. The deployment that this link enabled is described in Cloudflare Cron Triggers Not Firing? Use a Durable Object Alarm and Cloudflare Workflows Free Plan: Retries, Steps and Fatal Errors.

FAQ

Which permissions does a token need to deploy a Worker with KV, Workflows and Durable Objects?

In our setup four entries were enough: Workers Scripts (edit), Workers KV Storage (edit), D1 (edit, only if you use D1) and Account Settings (read). Workers Scripts also covered the Workflow and the Durable Object migration.

Can the dashboard pre-fill a custom API token?

Yes. The create-token page accepts query parameters: permissionGroupKeys with a URL-encoded JSON list of permission keys and levels, plus accountId, zoneId and name. We did not find this documented, but it worked in October 2026, so treat it as a convenience that may change.

Do I need to look up my account ID?

Not if you have the token: calling GET /accounts with it returns your accounts and their IDs, and a deploy script can pick the first one.

Does the running Worker need the token?

No. The token is only for deploying. Our production Worker holds a single secret (an admin key), so the token can be revoked after launch and recreated from the same link when you want to deploy again.