Cloudflare package v1.0.0

A Cloudflare API token for the customer's own account, held in the client's own secret manager. The stored material must be the complete Authorization header value: the scheme 'Bearer', one separating space, then the token — 'Bearer <token>'.

Issuance is external: a user creates the token in the Cloudflare dashboard (My Profile > API Tokens), choosing the token's permission groups and the zones and accounts it covers; the token value is shown once at creation, so capture it into the vault at that moment.

Least privilege: grant only the permissions the registered capabilities need — Zone.Zone Read for the zone collection read, Zone.DNS Read/Edit on the bound zone(s) for the DNS capabilities (according to the reviewed DNS records list reference, the endpoint accepts DNS Read or DNS Write), and Cache Purge only where the purge capability is enabled — and scope the token to the specific zones the deployment binds, not All zones.

Expiry and revocation: a token may be created with an optional TTL, after which it fails closed, but a token without one does not expire on its own; revocation is rolling or deleting the token in the dashboard — according to the reviewed roll-token reference (PUT /client/v4/user/tokens/{token_id}/value, requiring the API Tokens Write permission) and Cloudflare's roll-token how-to, rolling generates a new secret and invalidates the previous token while keeping its access and permissions, and the retrieved pages document no grace period, so treat the old value as dead once the roll returns; deleting a token is immediate — and disabling issuance, or the creating user losing permission to create tokens, does not invalidate tokens already issued: each issued token must be rolled or deleted individually.

Rotation therefore sits with an external deployment process: the executor injects the stored value verbatim and performs no token lifecycle of its own. Alternative two-header authentication: Cloudflare also still accepts the legacy Global API Key scheme, which authenticates with TWO headers — X-Auth-Email (the account email) plus X-Auth-Key (the global key); according to the reviewed get-started reference the Global API Key is the previous scheme and is less secure than API tokens, and this pack registers the single Bearer header only — a deployment that insists on the legacy key must wire both headers itself and accept that the global key is unscoped and grants everything the account can do.

Executor hygiene: the value must live only in executor memory for the lifetime of a call, must never be written to logs, traces or diagnostics, and must not appear in crash dumps; a deployment that cannot meet that bar must not enable the pack.

The endpoint host 'api.cloudflare.invalid' is a reserved non-production placeholder (an RFC 2606 reserved TLD): substitute the real Cloudflare API authority (api.cloudflare.com, or the customer's API host for a partner/custom deployment) before enabling, in every endpoint, in the resource locators and in every egress allowlist entry. The allowlist matches exactly, so endpoints and allowlist must be substituted together, and substitution is a required deployment step. ZONE_ID and DNS_RECORD_ID in the endpoint paths are placeholders the deployment binds to concrete identifiers before enabling.

Every read endpoint here is a collection read: single-record reads (GET one zone, GET one DNS record) are not registered.

Approval classification: DNS record creation registers as create and deploy, and edit as update and deploy, at the minimum R3 tier: creating or editing A, AAAA, CNAME or MX records provisions or reroutes production traffic routing — a deploy-equivalent effect on live infrastructure, and deploy is one of the designated actions requiring human approval — so it requires that action’s minimum tier; only the partial-edit PATCH is registered, not the PUT overwrite.

DNS record deletion registers as delete at the minimum R3 tier: removing the record that resolves a name can take the service behind it offline — the outage is neither immediate nor guaranteed, because resolver caches and unexpired TTLs can keep stale answers alive until they lapse — and delete is one of the designated actions requiring human approval.

Cache purge registers as delete at the minimum R3 tier, judged by effect: the endpoint's caller-controlled body accepts purge_everything=true, which according to the reviewed purge reference removes all files from the zone's cache in every Cloudflare data center and forces all subsequent requests back to the origin — a broad-impact burst of origin load — so an unrestricted body defeats any lower tier, and purge is treated as an irreversible-action equivalent.

Excluded operations: zone creation and zone deletion (DELETE /zones/{zone_id} removes the whole zone and every record and setting in it), the DNS record PUT overwrite, zone settings changes (SSL mode, security level, TLS minimum), WAF and firewall rules, Page Rules and cache rules, Workers scripts and routes, Load Balancers, API token creation/verification/roll and user or account membership management, registrar operations, and every other Cloudflare API.