Docs Collections Release Notes

We're announcing the public beta of Organizations for enterprise customers, a new top-level Cloudflare container that lets Cloudflare customers manage multiple accounts, members, analytics, and shared policies from one centralized location.

What's New

Organizations [BETA]

are a new top-level container for centrally managing multiple accounts. Each Organization supports up to 500 accounts and 500 zones, giving larger teams a single place to administer resources at scale.

Self-serve onboarding

Enterprise customers can create an Organization in the dashboard and assign accounts where they are already Super Administrators.

Centralized Account Management

At launch, every Organization member has the Organization Super Admin role. Organization Super Admins can invite other users and manage any child account under the Organization implicitly.

Shared policies

Share WAF or Gateway policies across multiple accounts within your Organization to simplify centralized policy management.

Implicit access

Members of an Organization automatically receive Super Administrator permissions across child accounts, removing the need for explicit membership on each account. Additional Org-level roles will be available over the course of the year.

Unified analytics

View, filter, and download aggregate HTTP analytics across all Organization child accounts from a single dashboard for centralized visibility into traffic patterns and security events.

Terraform provider support

Manage Organizations with infrastructure as code from day one. Provision organizations, assign accounts, and configure settings programmatically with the Cloudflare Terraform provider.

Shared policies

Share WAF or Gateway policies across multiple accounts within your Organization to simplify centralized policy management.

Note

Organizations is in Public Beta. You must have an Enterprise account to create an organization, but once created, you can add accounts of any plan type where you are a Super Administrator.

For more info:

• Get started with Organizations
• Set up your Organization
• Review limitations

Service Key authentication for the Cloudflare API is deprecated. Service Keys will stop working on September 30, 2026.

replace Service Keys with fine-grained permissions, expiration, and revocation.

What you need to do

Replace any use of the

X-Auth-User-Service-Key

header with an

API Token

scoped to the permissions your integration requires.

If you use

cloudflared

, update to a version from November 2022 or later. These versions already use API Tokens.

If you use

origin-ca-issuer ↗
origin-ca-issuer
↗

, update to a version that supports API Token authentication.

For more information, refer to

API deprecations
.

Cloudflare dashboard SCIM provisioning now supports Authentik ↗

Authentik

↗

as an identity provider, joining Okta and Microsoft Entra ID as explicitly supported providers.

Customers can now sync users and group information from Authentik to Cloudflare, apply Permission Policies to those groups, and manage the lifecycle of users & groups directly from your Authentik Identity Provider.

Note

SCIM provisioning for the Cloudflare dashboard is available to Enterprise customers. You must be a Super Administrator to complete the initial setup.

For more information:

• SCIM provisioning overview
• Provision with Authentik

Cloudflare dashboard SCIM provisioning operations are now captured in Audit Logs v2

Cloudflare dashboard SCIM provisioning operations are now captured in Audit Logs v2, giving you visibility into user and group changes made by your identity provider.

Logged actions

• Create SCIM User | User provisioned from IdP
• Replace SCIM User | User fully replaced (PUT)
• Update SCIM User | User attributes modified (PATCH)
• Delete SCIM User | Member deprovisioned
• Create SCIM Group | Group provisioned from IdP
• Update SCIM Group | Group membership or attributes modified
• Delete SCIM Group | Group deprovisioned

For more details, refer to the Audit Logs v2 documentation.

Changes

Cloudflare-generated 1xxx error responses now include a standard Retry-After HTTP header when the error is retryable. Agents and HTTP clients can read the recommended wait time from response headers alone — no body parsing required.

Seven retryable error codes now emit Retry-After:

Error code | Retry-After (seconds) | Error name
1004 | 120 | DNS resolution error
1005 | 120 | Banned zone
1015 | 30 | Rate limited
1033 | 120 | Argo Tunnel error
1038 | 60 | HTTP headers limit exceeded
1200 | 60 | Cache connection limit
1205 | 5 | Too many redirects

The header value matches the existing retry_after body field in JSON and Markdown responses.

If a WAF rate limiting rule has already set a dynamic Retry-After value on the response, that value takes precedence.

Availability

Available for all zones on all plans.

Verify

Check for the header on any retryable error:

curl -s --compressed -D - -o /dev/null -H "Accept: application/json" -A "TestAgent/1.0" -H "Accept-Encoding: gzip, deflate" "<YOUR_DOMAIN>/cdn-cgi/error/1015" | grep -i retry-after

References:

• RFC 9110 section 10.2.3 - Retry-After
• Cloudflare 1xxx error documentation

Breaking change

The Markdown frontmatter field
http_status has been renamed to
status. Agents consuming Markdown frontmatter should update parsers accordingly.

Changes

JSON format.
Clients sending
Accept: application/json or
Accept: application/problem+json now receive a structured JSON object with the same operational fields as Markdown frontmatter, plus RFC 9457 standard members.

RFC 9457 standard members (JSON only):

• type — URI pointing to Cloudflare documentation for the specific error code
• status — HTTP status code (matching the response status)
• title — short, human-readable summary
• detail — human-readable explanation specific to this occurrence
• instance — Ray ID identifying this specific error occurrence

Field renames:

• http_status -> status (JSON and Markdown)
• what_happened -> detail (JSON only — Markdown prose sections are unchanged)

Content-Type mirroring.
Clients sending
Accept: application/problem+json receive
Content-Type: application/problem+json; charset=utf-8 back;
Accept: application/json receives
application/json; charset=utf-8. Same body in both cases.

Negotiation behavior

• Request header sent | Response format
• Accept: application/json -> JSON (application/json content type)
• Accept: application/problem+json -> JSON (application/problem+json content type)
• Accept: application/json, text/markdown;q=0.9 -> JSON
• Accept: text/markdown -> Markdown
• Accept: text/markdown, application/json -> Markdown (equal q, first-listed wins)
• Accept: / -> HTML (default)

Availability

Available now for Cloudflare-generated 1xxx errors.

Get started

Cloudflare Workflows retry logic

Cloudflare Workflows allows you to configure specific retry logic for each step in your workflow execution. Now, you can access
which retry attempt is currently executing for calls to
step.do() :

await step.do(
  "my-step",
  async (ctx) => {
    // ctx.attempt is 1 on first try, 2 on first retry, etc.
    console.log(`Attempt ${ctx.attempt}`);
  }
);

You can use the step context for improved logging & observability, progressive backoff, or conditional logic in your workflow definition.

Note that the current attempt number is 1-indexed. For more information on retry behavior, refer to Sleeping and Retrying.

Real-time transcription in RealtimeKit now supports 10 languages with regional variants

in RealtimeKit now supports 10 languages with regional variants, powered by Deepgram Nova-3 running on Workers AI.

During a meeting, participant audio is routed through AI Gateway to Nova-3 on Workers AI — so transcription runs on Cloudflare's network end-to-end, reducing latency compared to routing through external speech-to-text services.

Set the language when creating a meeting via ai_config.transcription.language :

{
 "ai_config" : {
  "transcription" : {
   "language" : "fr"
  }
 }
}

Supported languages include English, Spanish, French, German, Hindi, Russian, Portuguese, Japanese, Italian, and Dutch — with regional variants like en-AU , en-GB , en-IN , en-NZ , es-419 , fr-CA , de-CH , pt-BR , and pt-PT . Use multi for automatic multilingual detection.

If you are building voice agents or real-time translation workflows, your agent can now transcribe in the caller's language natively — no extra services or routing logic needed.

• Transcription docs
• Nova-3 model page
• Workers AI
• AI Gateway

Region filtering

All location-aware pages now support filtering by region, including continents, geographic subregions (Middle East ↗, Eastern Asia ↗, , etc.), political regions (EU ↗, , African Union ↗, ), and US Census regions/divisions (for example, New England ↗, US Northeast ↗, ).

Traffic volume by top autonomous systems and locations

A new traffic volume view shows the top autonomous systems and countries/territories for a given location. This is useful for quickly determining which network providers in a location may be experiencing connectivity issues, or how traffic is distributed across a region.

The new AS and location dimensions have also been added to the Data Explorer ↗ for the HTTP, DNS, and NetFlows datasets. Combined with other available filters, this provides a powerful tool for generating unique insights.

Finally, breadcrumb navigation is now available on most pages, allowing easier navigation between parent and related pages.

Check out these features on Cloudflare Radar ↗ .

Browser Rendering REST API rate limits

Browser Rendering REST API rate limits for Workers Paid plans have been increased from 3 requests per second (180/min) to 10 requests per second (600/min). No action is needed to benefit from the higher limit.

The REST API lets you perform common browser tasks with a single API call, and you can now do it at a higher rate.

If you use the Workers Bindings method, increases to concurrent browser and new browser limits are coming soon. Stay tuned.

For full details, refer to the Browser Rendering limits page.