Cloudflare Setup
Flarepipe: Chat needs one broadly-scoped token for a few minutes, and a very narrow one thereafter. This page covers what to grant, why, what gets created, and what is left behind.
Creating the setup token
In the Cloudflare dashboard go to My Profile > API Tokens > Create Token and use the custom token option. The setup wizard links you straight there.
Always required
| Permission | Why |
|---|---|
| Account → Workers Scripts → Edit | Upload the Worker that answers questions. |
| Account → Workers AI → Edit | Bind the models. Read is not sufficient, because the Worker has to invoke them. |
| Account → Vectorize → Edit | Create the index your content is stored in. |
| Account → Account Settings → Read | Resolve your account ID and workers.dev subdomain. |
| User → API Tokens → Edit | Mint the minimal replacement token, and delete this setup token afterwards. |
Only for a custom domain
Add these if you want the bot served from something like chat.yoursite.com instead of a workers.dev URL:
| Permission | Why |
|---|---|
| Zone → Zone → Read | Find the zone the hostname belongs to. |
| Zone → DNS → Edit | Create the record pointing at the Worker. |
| Zone → SSL and Certificates → Edit | Issue the certificate for the hostname. |
| Zone → Workers Routes → Edit | Attach the Worker to the hostname. |
| Zone → WAF → Edit | Add a zone-level rate limiting rule as a second layer of abuse protection. |
If you skip the zone permissions the setup still succeeds: it falls back to account-only scope and serves from workers.dev.
What gets created in your account
- A Vectorize index named after a short hash of your site URL, with 768 dimensions and cosine similarity. The hash means one Cloudflare account can host chatbots for many sites without collisions.
- A Worker with the same name, bound to Workers AI, that index, a plain-text config blob, and a Durable Object used as a rate limiter.
- A workers.dev subdomain, if your account does not already have one.
- A Worker secret holding a 64-character random value that gates content ingestion, so only your site can write to the index.
- Optionally, a Worker custom domain and a zone rate limiting rule.
Settings changes redeploy the Worker with an updated config blob rather than reading from KV at runtime. That is one fewer service to provision and one fewer thing to break; the trade-off is that saving settings takes a moment longer.
What happens to the token
This is the part worth understanding, because it is the main security difference from most plugins that ask for an API key.
- The setup token is never written to your database. It exists in the browser and in the bodies of the setup requests, and nowhere else.
- Once provisioning succeeds, a new token is minted scoped to just Workers Scripts Edit and Vectorize Edit on the one account (plus the zone groups if you used a custom domain). That is the minimum needed to redeploy the Worker on plugin updates and to rebuild the index.
- That replacement token is stored encrypted with AES-256-GCM, keyed from your site's WordPress salts.
- The setup token is asked to delete itself from your Cloudflare account.
So the credential sitting on your site long-term cannot read your account settings, cannot touch DNS, cannot create tokens, and cannot see anything outside the chatbot's own resources.
Tokens belong to people, not accounts
Cloudflare API tokens are owned by the user who created them. If that person leaves the Cloudflare account, the token dies with their access and the plugin will need re-onboarding by someone still on the account. If you are setting this up for a client, think about whose login you use.
Attaching a custom domain later
You do not have to decide during setup. The settings screen has a serving domain section where you can attach or remove a custom hostname afterwards. Requirements: the zone must be on the same Cloudflare account, and there must be no existing DNS record for that exact hostname. Certificate issuance can lag a few minutes after attaching, so a brief period of TLS warnings is expected before it settles.
Re-running setup
Every provisioning step treats an "already exists" response as success, so running setup again is a repair operation rather than a duplication risk. If the Worker got deleted, or the index was removed, or a step failed halfway, create a fresh setup token and run the wizard again.