Cloudflare setup

​

Part 1: Cloudflare Data Ingestion

Set up a Cloudflare app so ConfigView can pull your Cloudflare data into the dashboard.

---

​

Step 1: Create an API Token

1. Open the API Tokens page directly: https://dash.cloudflare.com/profile/api-tokens (in the dashboard this is the user menu in the top-right → My Profile → API Tokens).
2. Click the blue Create Token button.
3. Scroll to the bottom of the template list to Create Custom Token and click Get started.
4. Give the token a Token name you’ll recognize, e.g. ConfigView.
5. Under Permissions, add one row per item below. Each row is three dropdowns — Group, then Permission, then Access level. Click + Add more to add another row.

   Group	Permission	Access	Needed for
   Account	Account Settings	Read	Members, Roles, Account Settings, User Groups
   Account	Access: Organizations, Identity Providers, and Groups	Read	Access Groups (Zero Trust)
   Account	Workers Scripts	Read	Workers
   Account	API Tokens	Read	API Tokens
   Account	Billing	Read	Subscriptions
   Account	Registrar	Read	Domain registration data
   Account	Audit Logs	Read	Audit Logs
   Account	Cloudflare Tunnel	Read	Tunnels
   Account	Notifications	Read	Notification Policies
   Account	Custom Pages	Read	Custom Pages
   Zone	Zone	Read	Domains (zones)

6. Under Account Resources, choose Include → your account. Under Zone Resources, choose Include → All zones from an account → your account.
7. Click Continue to summary, then Create Token.
8. Copy the token value now — Cloudflare shows it only once. If you lose it you’ll have to roll it (see below).

​

Editing an existing token

If a ConfigView token already exists but some scripts fail their health check, it most likely has too few permissions. You cannot view an existing token’s secret value, but you can change its permissions:

1. Go to https://dash.cloudflare.com/profile/api-tokens.
2. Find the token in the list, click the ⋯ (or Edit) action on its row.
3. Add any missing rows from the permissions table above, then Continue to summary → Save.
4. Saving permission changes does not change the token value, so you do not need to update the secret in ConfigView.
5. If you don’t have the original token value (e.g. it was never saved), use Roll to generate a new value, then update CLOUDFLARE_API_TOKEN in ConfigView (Step 2).

​

Find your Account ID

Open https://dash.cloudflare.com, select your account, and copy the Account ID from the right-hand sidebar (also visible in the address bar: dash.cloudflare.com/<account_id>).

---

​

Step 2: Add the Token to ConfigView

1. Go to your ConfigView dashboard: https://{companyname}.configview.com/admin/secret/
2. Click Add Secret
3. Create the following secrets:
   • CLOUDFLARE_API_TOKEN: The API token you just created
   • CLOUDFLARE_ACCOUNT_ID: Your Cloudflare Account ID
4. Click Save

---

​

Step 3: Enable the Cloudflare App in ConfigView

1. Go to: https://{companyname}.configview.com/admin/cron/
2. You should see Cloudflare in the list of available apps
3. Select the scripts you want to run.
4. Click Save

---

​

Step 4: Verify

1. Go to: https://{companyname}.configview.com/admin/status/
2. Run the Cloudflare health check.
3. All checks should pass.

If a check fails, verify that your secrets are saved correctly and the token has the required permissions.

---

​

Available Scripts

Note: Cloudflare exposes products, licenses, and billing through a single subscriptions endpoint — each subscription’s rate_plan is the product/license tier and the price, currency, frequency, and state fields describe the billing.

Account Settings is small but load-bearing. A member’s api_access_enabled has three states, and the most common one is null, meaning inherit the account setting. Without this one-row table there is no way to resolve what a member’s API access actually is — only whether someone set a per-member override. Enable it alongside Members.

---

​

Configuring Audit Logs

Audit Logs behaves differently from the other twelve collectors in two ways, both adjustable without a code change. It records dashboard actions only, by default. Cloudflare audits every automated operation as well — DNS writes, Workers deployments, image uploads, cache purges. On a real account that was 1,228 of 1,533 events over a week (about 80%), burying the changes anyone reviews access with. The collector therefore keeps only events a person performed in the Cloudflare dashboard. It reads a look-back window rather than a snapshot. It asks for the last 7 days on each run and deduplicates on Cloudflare’s event id, so a window wider than your schedule interval is deliberate — it backfills events that a failed or skipped run would otherwise have lost permanently.

The default also excludes administrative changes made through an API token or SCIM, including SSO logins and token updates — those arrive with actor context api, not dash. If you need them, widen CLOUDFLARE_AUDIT_ACTOR_CONTEXTS to dash,api rather than turning the filter off entirely.

Note that filtering does not reduce API usage. Cloudflare cannot filter audit events server-side, so the collector still pages the whole window and discards on the way in. Each run reports how many events it kept versus filtered out, so a large drop count is visible rather than looking like a collection failure.

---

​

Data Tables

Once the scripts run, the corresponding Cloudflare tables will be created in your database. All tables include a run_at column for historical tracking and a raw JSON column with the full Cloudflare object. cloudflare_audit_logs is the one exception to snapshot semantics: it is append-only, so run_at records which collection first wrote each event rather than marking a full snapshot. Query it by action_time, not by run_at.