Cloudflare Deprecates the Account Roles API

A terminal window showing the real Cloudflare changelog entry: the Account Roles API only returns account-level roles today, and is deprecated in favor of the Permission Groups API
On this page

What’s actually changing

Cloudflare’s own changelog entry gives a real functional gap as its reasoning for the deprecation, not just a naming preference:

“The Account Roles API only returns account-level roles today, and is deprecated in favor of the Permission Groups API”

The Account Roles API’s whole limitation was scope: it only ever surfaced account-level roles, a flat list like “Administrator” or “Billing.” The Permission Groups API, confirmed live at GET /accounts/{account_id}/iam/permission_groups, returns a paginated array of permission groups, each a named group of fine-grained permissions mapped to specific operations against specific resources, a genuinely different and more expressive model.

Structural Comparison Matrix

Operational AspectAccount Roles API (deprecated)Permission Groups API
Data modelFlat list of account-level role namesNamed groups of fine-grained permissions
List endpointGET /accounts/{account_id}/rolesGET /accounts/{account_id}/iam/permission_groups
FilteringNot documented for this endpointOptional name query parameter
GranularityWhole role onlyIndividual permission-to-operation mappings

Fix it: migrate the logic, not just the URL

before: listing flat account roles
curl -X GET \
  "https://api.cloudflare.com/client/v4/accounts/<account_id>/roles" \
  -H "Authorization: Bearer <api_token>"
after: listing permission groups
curl -X GET \
  "https://api.cloudflare.com/client/v4/accounts/<account_id>/iam/permission_groups" \
  -H "Authorization: Bearer <api_token>"

This is a data-model migration, not a URL swap

Automation that checks if role.name == "Administrator" against the old API has no direct equivalent field to swap in. The Permission Groups API models permissions, not a single named role, so gating logic built around role names needs to be rebuilt around specific permission group membership instead, real design work, not a one-line change.

Before rewriting anything, pull the actual permission groups available on the account and map which ones correspond to the old role-based checks the automation relied on:

find the permission groups an account actually has
curl -X GET \
  "https://api.cloudflare.com/client/v4/accounts/<account_id>/iam/permission_groups?name=Administrator" \
  -H "Authorization: Bearer <api_token>"

Confirmed version

Sourced from Cloudflare’s official changelog, published 2026-07-21, deprecation effective the same day, corroborated by Cloudflare’s own live API reference for the Permission Groups API endpoint. Browse more posts like this in the Data Automation archive.

Frequently asked

Is this a simple endpoint rename, like the KV routes deprecation?

No. The KV deprecation is a pure URL path swap with identical request/response shapes. This one changes the underlying data model: a flat list of named account-level roles becomes a set of fine-grained permission groups. Automation checking `if role == 'Administrator'` needs real logic changes, not a find-and-replace on the endpoint path.

Does this have a hard end-of-life date yet?

Cloudflare's changelog for this entry states the deprecation as effective 2026-07-21 without a separate end-of-life date in what's publicly documented for this specific entry. Treat the deprecation date as the signal to migrate, and check Cloudflare's current API deprecations reference for an EOL date before assuming there's no deadline at all.

Emitted as FAQPage JSON-LD from the same frontmatter — one source, no duplicated prose.

Recent posts

Full-text search via Pagefind · ↑↓ to navigate · ↵ to open