Account Owned Tokens reach general availability
Cloudflare has announced general availability for Account Owned Tokens, a new option for managing how applications and integrations authenticate against the Cloudflare API. The feature addresses a long-standing limitation: previously, API tokens were always tied to an individual user account. That model works for personal projects but creates real friction for organizations, where a service might outlive a user's tenure or need to be managed by more than one person.
The distinction matters because Cloudflare Users and Accounts are different entities. A User is a person who signs in with an email address. An Account is the top-level container that organizes all of a customer's Cloudflare resources, and it can have multiple users for collaboration. In practice, that means [email protected] might be the user, while the account is "Example Company."
Key mechanics:
- Account Owned Tokens are scoped to the account that owns them, not to a specific user's permissions.
- An individual user can never create a token that grants permissions they don't have themselves.
- The tokens are visible and manageable by all Super Administrators on the account.
- Audit logs attribute actions to the named token (for example, "compliance workflow") rather than to an individual user.
Consider a compliance workflow that needs to pull zone lists and verify security settings. Previously, that meant having a user create a token and then attributing every automated action to that person. If that employee left and their credentials were revoked, the workflow would break. With an Account Owned Token named "compliance workflow," the token's access is independent of any single user. Super admins can view, edit, roll, or delete it, and all actions are logged to the service identity, keeping user permissions minimal.
Where the tokens live
Account Owned Tokens are available under the new "API Tokens" tab in the "Manage Account" section of the Cloudflare dashboard. The API uses the same semantics as before but at a new endpoint: /account/<accountId>/tokens.
Deciding between token types
Cloudflare recommends switching to Account Owned Tokens in several specific situations. For long-running services that multiple people manage, these tokens remove the single-person bottleneck for edits, rotations, and deletions, while also protecting against user lifecycle events. They are also the right choice for accounts that need attestable access records beyond simple user membership: by restricting users from direct API access and consolidating all usable tokens into a single account-level list, customers get a complete picture of API access in one dashboard location.
They also offer a safer alternative for organizations that previously created "Service Users"—identities meant to allow multiple people to access Cloudflare. Those highly privileged shared logins are an active threat surface requiring vaulting, password rotation, and monitoring for non-repudiation. If the operations only need API access, an Account Owned Token consolidates that access more cleanly.
User Owned Tokens still make sense in other cases. They remain the right choice when programmatic access is tied to a single person working through an external interface, since having access traced back to the individual is desirable. Any user-level operations—email changes, password changes, user preferences—still require a user-level token. And because Account Owned Tokens are currently scoped to a single account, any operation that needs to span multiple accounts with one credential should still use a User Owned Token.
There are also compatibility and management constraints to be aware of. As of November 2024, Cloudflare is still working through its services to ensure full Account Owned Token support. For endpoints that lack support, User Owned Tokens remain necessary. Likewise, organizations that need to create and delete tokens programmatically in large numbers should stick with user-owned tokens for now. Cloudflare expects the endpoint coverage work to be complete by Q3 2025 and has published a list of supported and unsupported services in its documentation.
Zaraz Automated Actions streamline third-party tooling
Alongside the token announcement, Cloudflare has launched Zaraz Automated Actions, a feature aimed at simplifying event tracking and tool integration for third-party services. The new capability automates common actions—pageviews, custom events, and e-commerce tracking—that previously required manual configuration.
Details on the mechanics and rollout for Zaraz Automated Actions were published in the Cloudflare blog announcement, alongside the Account Owned Tokens update.
Zaraz Automated Actions: Event tracking without the setup work
Cloudflare Zaraz loads third-party tools such as analytics, marketing tags, and social media scripts through Cloudflare's network, which cuts down on page load time and keeps user data from being exposed to external services directly. Historically, getting a tool running in Zaraz required a manual chain of configuration steps: first you had to set up a trigger, then bind that trigger to an action in the tool, and finally call zaraz.track() to fire the event. That structure supported complex conditional rules, but it also meant users had to understand the relationship between triggers and actions just to fire a simple event.
Automated Actions is a new feature meant to remove that friction. It applies the philosophy behind zaraz.ecommerce() — where an event type automatically maps to the appropriate tool configuration — to every event category. Now calling zaraz.track(‘myEvent’) forwards the event to the configured tool with no trigger or action definitions required.
Three automations to choose from
When you add a new tool in Zaraz, the setup flow now includes a step where you select an automation mode. You can pick one of three options:
- Pageviews: every page visit is sent to the tool automatically.
- All other events: any custom event fired via
zaraz.track()is delivered to the tool. - Ecommerce: events triggered with
zaraz.ecommerce()are pushed to the tool for transaction and sales tracking.
Existing tools also get the treatment. From the tool detail page in the Zaraz dashboard, you can flip each automation on or off independently, so you have control over which event types flow automatically to each integration.
Not every tool supports this shortcut, though. If a tool doesn't have native support for page view, custom, or e-commerce events, you can build custom actions the old way, which still works as before: create a trigger first (or reuse one), then configure the action. Cloudflare's Create Actions guide documents the steps in full.
Richer payloads with less work
Custom actions have also gained a convenience feature for payload enrichment. The Include Event Properties toggle, when switched on, automatically attaches client-side data you passed to the event call. For example, firing zaraz.track(‘click’, { userID: “foo” }) sends the userID property along with the event, so you don't have to map data fields manually inside the action.
A second option, Include System Properties, adds environment-level metadata such as browser and operating system info. To enable it, open your action settings, click “Add Field,” select “Include System Properties,” confirm, and toggle it on. A reference guide on Cloudflare's developer docs lists all available system properties.
These two fields replace the old “Enrich Payload” dropdown, which has been deprecated.
