Changelog

The Cloudflare Status page at www.cloudflarestatus.com ↗ has been rebuilt. It is available at the same address, and every previously documented Status API ↗ endpoint remains supported, so existing bookmarks, integrations, and monitoring continue to work.

The status page now has its own notification system, delivered independently of Cloudflare infrastructure. You can subscribe by email, webhook, Slack, Discord, or Google Chat.

The Maintenance Notification and Incident Alerts in Cloudflare Notifications remain supported, and deliver to the destinations already configured on your account.

Every page on the status page returns Markdown when requested with an Accept: text/markdown header, so agents can read the current status without parsing HTML:

curl -H "Accept: text/markdown" https://www.cloudflarestatus.com/locations

Incidents and maintenance are published as separate feeds, each available in RSS and Atom, so you can subscribe to one without the other:

https://www.cloudflarestatus.com/api/v3/incidents.rss
https://www.cloudflarestatus.com/api/v3/incidents.atom
https://www.cloudflarestatus.com/api/v3/maintenance.rss
https://www.cloudflarestatus.com/api/v3/maintenance.atom

For more information, refer to Cloudflare Status.

Hostname routing ↗ is now generally available. Instead of managing static IP lists and routes, you can route traffic by hostname across multiple Cloudflare One connectors:

• Cloudflare Tunnel: route a private hostname (for example, wiki.internal.local) to a private application behind your tunnel, or a public hostname (for example, bank.example.com) to egress through a specific tunnel and anchor traffic to a dedicated exit node.
• Cloudflare Mesh: attract a private or public hostname's traffic to a Mesh node.

Alongside GA, the default IPv4 range used for initial resolved IPs (also called token IPs) is changing from a Carrier-Grade NAT (CGNAT) range to a public Cloudflare-owned range:

• IPv4: 172.64.128.0/20
• IPv6: 2606:4700:0cf1:4000::/64

This is the default range. You can configure a custom initial resolved IP range for IPv4 if it conflicts with your existing network.

Why this is changing: Starting with Chrome 142 ↗, Local Network Access (LNA) restrictions block background requests to CGNAT addresses (100.64.0.0/10), which included the previous initial resolved IP default (100.80.0.0/16). LNA is implemented at the Chromium engine level, so it affects all Chromium-based browsers (for example, Microsoft Edge, Brave, and Opera), not only Google Chrome. This could silently break hostname-based Gateway features for users of these browsers, and required Chrome Enterprise policy workarounds. The new default range is public Cloudflare address space, so it is not affected by this restriction.

What is affected: Initial resolved IPs are used by several features that associate a DNS query with the network connection that follows it:

• Private and public hostname routing for Cloudflare Tunnel
• Hostname routes for Cloudflare Mesh
• Access private applications on non-HTTPS ports
• Egress policy host selectors (Domain, Host, Application, and Content Categories)

You can check your account's current range, or configure a custom range, at any time from Zero Trust > Team & Resources > Devices > Device profiles, or using the Initial Resolved IP Subnet API.

For full instructions, refer to Configure initial resolved IPs. The IPv6 range (2606:4700:0cf1:4000::/64) is unchanged and is not affected by this restriction.

If you were relying on a Chrome Enterprise policy workaround (such as LocalNetworkAccessRestrictionsTemporaryOptOut) while your account was still on the legacy CGNAT-based range, refer to Google Chrome restricts access to private hostnames for next steps.

Real-time Tunnel log streaming is now available in the Cloudflare dashboard under Networking > Tunnels. This brings the same live debugging capability previously only available in the Cloudflare One dashboard, including multi-connector aggregated streaming for high-availability deployments.

In the tunnel detail view, a new Live logs tab lets you:

• Stream logs from single or multiple connectors — In highly available deployments with multiple cloudflared replicas, logs from all connectors are merged into a single stream grouped by hostname, making it easy to identify which host machine produced each log entry.
• Filter by log level, event type, and HTTP method — Narrow the stream to only the events you care about (HTTP, TCP, UDP, or cloudflared internal), at any log level.

For more information, refer to Monitor tunnels and Tunnel log streams.

OAuth consent screens now display a shield icon with explanatory text beneath the consent screen title. Each shield icon indicates who owns the application and whether its domain ownership is verified.

• Green filled shield: Cloudflare owns and manages the application.
• Blue outlined shield: A third-party application with verified ownership of its domain.
• Amber filled shield: A third-party application without verified ownership of a domain.

Domain verification only confirms that the application owner controls the displayed domain.

For more information, refer to Authorizing an application.

You can now create standalone Free accounts directly from the Cloudflare dashboard using the new Create Account button. This feature is currently available to all users.

When creating a Free account:

• You can create up to 5 Free accounts.
• Your user account must have at least 7 days of tenure to be eligible.
• The account is created immediately and ready to use.

To create a Free account, go to the Cloudflare dashboard ↗ and select Create Account from either the account switcher in the top left (where your account name appears) or from the Accounts page.

• This feature can only be used to create a Cloudflare Free account. To create an Enterprise Account under your existing contract, please contact Cloudflare Support.
• All users can create a Cloudflare Free account, however, Enterprises wish to restrict this action to only Super Administrators. We will deliver this improvement in a future release.

After creating your Free account, you can:

• Add a payment method to enable additional Cloudflare products and services.
• Update billing information to manage payment methods, billing address, or tax IDs.
• Review how Cloudflare billing works to understand the billing lifecycle and charge types.
• Assign accounts to an Enterprise Organization to centrally manage multiple accounts from a single dashboard.

Audit Logs v2 now includes Resource History. For any audit log entry, you can see the sequence of previous changes to the same resource and view a side-by-side diff of what was modified.

Resource History uses the audit log entries you already have. There is no additional configuration, no backend recapture, and no changes to how audit logs are generated.

Dashboard:

1. Go to Manage Account > Audit Logs.
2. Open any audit log entry.
3. Select the History tab to see the full history for that resource.
4. Select any earlier entry to see a side-by-side diff of the fields that changed between it and the current entry.

API:

Use the History endpoint to retrieve the change history for any audit log entry:

GET https://api.cloudflare.com/client/v4/accounts/{account_id}/logs/audit/{id}/history

The endpoint is also available for organization-scoped audit logs at /organizations/{organization_id}/logs/audit/{id}/history.

For more information, refer to the Resource History documentation.

The Account Roles API is deprecated and is being replaced by the Permission Groups API. An end of life date has not yet been established.

Review the Permission Groups API documentation; the response schema differs from the legacy Roles response.

• Integrations migrating to the Permission Groups API must obtain Permission Group IDs from that API and use them in the Account Members API policies request shape. Integrations that persist legacy Role IDs will need to remap their assignments.
• The legacy Role response includes a top-level description and a permissions object keyed by resource type with edit/read flags.
• The PermissionGroup response replaces those with a meta object containing label and scopes. Individual permissions are not returned as part of the permission group.
• The new API supports the API Token authorization scheme. The legacy Email + API Key authorization schema is provided for backwards compatibility.

For more information, refer to API deprecations.

We are turning on budget alerts by default for eligible Pay-as-you-go accounts. If your account does not already have a budget alert, Cloudflare will create one for you with a $10 account-level threshold. Your default alert will enable at the turn of your next billing cycle, so it will not fire based on usage you have already incurred.

We are rolling this out in cohorts over the coming weeks, so eligible accounts may see their default alert appear at different times.

The default alert behaves exactly like an alert you would create yourself. When your cumulative usage-based spend this cycle reaches the threshold, you receive an email notification. The alert is informational only. It does not cap your usage or impact your account in any way.

Usage is processed once per day for the prior day's activity, so budget alerts fire the day after the threshold is reached rather than in real time.

Budget alerts only consider spend on usage-based products. Recurring subscription fees, such as the Workers Paid plan fee or other monthly plan charges, are not included in the threshold calculation.

You can change the threshold, add additional alerts, or remove the default alert entirely from Manage Account > Billing > Billable Usage, or from your Notifications settings. If you already configured your own budget alert, nothing changes.

Enterprise contract accounts are not in scope.

For more information, refer to the Budget alerts documentation.

Distributor, MSSP, and Agency partners on Cloudflare Organizations can now add and manage Organization Members directly from the Cloudflare dashboard, without help from Cloudflare.

Previously, adding a member to a Distributor, MSSP, or Agency Organization was a manual, Cloudflare-assisted process that required a request to Cloudflare and enrollment in a closed beta, and the dashboard Add member flow was blocked for these Organizations.

Now, Organization admins can add members themselves from Organization > Members > Add member, with no beta enrollment required.

New members receive access to the Organization's accounts through the same implicit-access model already used for enterprise Organizations. The Accounts list and the account switcher classify Distributor, MSSP, and Agency Organizations consistently with enterprise Organizations, so their accounts are labeled and grouped correctly in the dashboard.

Agency partners also gain access to the Organizations dashboard, while retaining access to their existing Tenant management dashboard.

Distributor, MSSP, and Agency Organizations are currently in beta.

For more information, refer to Manage Organization members.

Cache Rules now supports bot management fields and the ip.src.asnum field in expression filters. You can now build cache policies that differentiate between automated and human traffic, or segment caching behavior by autonomous system number (ASN).

This allows you to apply different caching strategies for verified bots, high-risk traffic, or specific network operators without affecting legitimate user requests. For example, you can set shorter cache TTLs for suspected bot traffic or bypass cache entirely for requests from specific ASNs.

The following fields are now available in Cache Rules expressions:

Cache Rules expressions support combining these fields with other criteria. The following example sets a shorter cache TTL for API requests that originate from a high-risk bot or an unexpected ASN:

(http.request.uri.path contains "/api/" and cf.bot_management.score lt 30)
or
(http.request.uri.path contains "/api/" and not ip.src.asnum in {12345 67890})

To learn more, refer to the Cache Rules documentation and the Fields reference.

Markdown for Agents now preserves security- and cache-relevant response headers from your origin when converting HTML to Markdown:

• Markdown for Agents preserves security headers such as Strict-Transport-Security (HSTS), Content-Security-Policy (CSP), X-Frame-Options, Set-Cookie, and CORS headers (for example, Access-Control-Allow-Origin) on the converted response.
• Caching headers (Cache-Control, Expires, Age) continue to pass through.

Your origin's Content Signals ↗ policy is now authoritative. If your origin sets a content-signal header, Markdown for Agents preserves it. When the origin does not send one, Cloudflare adds the default Content-Signal: ai-train=yes, search=yes, ai-input=yes.

This release also fixes relative link resolution for directory-style base URLs (those ending in a trailing slash). Previously, relative links such as ../page/ could resolve one path segment too high and return a 404. Links are now resolved correctly per RFC 3986 ↗.

Refer to our developer documentation for more details.

On October 5, 2026, two changes take effect across the Zero Trust Networks API and Cloudflare Tunnel API: the CIDR-encoded route endpoints are removed, and tunnel list and get responses no longer include the connections field. If you manage private network routes or read tunnel connection details through the API, cloudflared, Terraform, or another integration, review the changes in the following sections and migrate before the removal date.

The CIDR-encoded route endpoints are deprecated in favor of the standard, route_id-based endpoints that already exist today. Both sets of endpoints route a private network through Cloudflare Tunnel or Cloudflare Mesh (the API still refers to Mesh nodes as warp_connector) — only the request shape changes.

Deprecated endpoints (removed October 5, 2026):

• Create a tunnel route (CIDR Endpoint): POST /accounts/{account_id}/teamnet/routes/network/{ip_network_encoded}
• Update a tunnel route (CIDR Endpoint): PATCH /accounts/{account_id}/teamnet/routes/network/{ip_network_encoded}
• Delete a tunnel route (CIDR Endpoint): DELETE /accounts/{account_id}/teamnet/routes/network/{ip_network_encoded}

Replacement endpoints:

• Create a tunnel route: POST /accounts/{account_id}/teamnet/routes
• Update a tunnel route: PATCH /accounts/{account_id}/teamnet/routes/{route_id}
• Delete a tunnel route: DELETE /accounts/{account_id}/teamnet/routes/{route_id}

1. Capture each route's route_id by calling List tunnel routes, or read it from the response the first time you create a route with the replacement endpoint.
2. Update any scripts, backend services, or CI/CD pipelines that call the CIDR-encoded endpoints directly.
3. If you manage routes with the cloudflared tunnel route ip add | delete commands, upgrade cloudflared to the latest version ↗.
4. If you manage routes with Terraform, make sure you are on a current version of the cloudflare_zero_trust_tunnel_cloudflared_route ↗ resource and the Cloudflare Terraform provider ↗.

# Before: create a route by URL-encoding the CIDR into the path
curl https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/routes/network/172.16.0.0%2F16 \
     -H 'Content-Type: application/json' \
     -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
     -d '{"tunnel_id": "'$TUNNEL_ID'", "comment": "Example comment for this route."}'

# After: create a route with the network in the request body
curl https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/routes \
     -H 'Content-Type: application/json' \
     -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
     -d '{"network": "172.16.0.0/16", "tunnel_id": "'$TUNNEL_ID'", "comment": "Example comment for this route."}'

# After: update or delete a route using its route_id
curl -X PATCH https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/routes/$ROUTE_ID \
     -H 'Content-Type: application/json' \
     -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
     -d '{"comment": "Updated comment for this route."}'

curl -X DELETE https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/routes/$ROUTE_ID \
     -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

Starting the same day, the connections array is removed from list and get responses for Cloudflare Tunnel and Cloudflare Mesh nodes (the cfd_tunnel and warp_connector API resources). Query the dedicated connections endpoint instead of reading the field off the tunnel or node object.

This affects:

• GET /accounts/{account_id}/cfd_tunnel — connections removed from each item in result
• GET /accounts/{account_id}/cfd_tunnel/{tunnel_id} — connections removed from result
• GET /accounts/{account_id}/warp_connector — connections removed from each item in result
• GET /accounts/{account_id}/warp_connector/{tunnel_id} — connections removed from result

Fetch connection details from the tunnel-specific connections endpoint instead of parsing it off the list or get response. For Cloudflare Tunnel, call GET /accounts/{account_id}/cfd_tunnel/{tunnel_id}/connections. For Cloudflare Mesh, call GET /accounts/{account_id}/warp_connector/{tunnel_id}/connections.

# Before: read connections off the tunnel object
curl https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/cfd_tunnel/$TUNNEL_ID \
     -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

# After: query connections directly
curl https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/cfd_tunnel/$TUNNEL_ID/connections \
     -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

Update any dashboards, monitoring scripts, or automation that parses connections from the tunnel list or get response. cloudflared and the Cloudflare Terraform provider do not read this field, so no changes are required on their side for this part of the update.

• Smaller, faster responses. Cloudflare Tunnel and Cloudflare Mesh nodes with many connections no longer inflate every list and get call — connection detail is only fetched when you need it.
• A single way to identify a route. Consolidating on route_id removes the need to URL-encode CIDR ranges into the path and matches how every other resource in the Zero Trust Networks API is addressed.
• Consistency across the API. Both changes align these endpoints with Cloudflare's standard REST conventions for resource identifiers and nested detail endpoints.

To learn more, refer to the Zero Trust Networks API, the Cloudflare Tunnel API, and Routes documentation.

Enterprise customers can now push per-connection WebSocket analytics to any Logpush destination using the new websocket_analytics dataset. Each log record is emitted when a WebSocket connection closes and includes fields that were previously only available to Cloudflare engineers via internal tooling.

Key fields include:

• ConnectionCloseReason — why the connection ended: peerReset, peerNoError, timedOut, upstreamReset, protocolViolation, unspecifiedError, or none.
• ConnectionCloseSource — which side initiated the close: upstream, downstream, me, or both.
• ConnectionTransportCloseCode — the TLS alert code or TCP-level close code for additional precision.
• RayID — correlate WebSocket connection events with your existing HTTP Request logs.

The dataset also includes directional byte counts (BytesSentClient, BytesReceivedClient, BytesSentOrigin, BytesReceivedOrigin), connection timestamps, client IP, colo code, and request metadata from the original WebSocket upgrade.

This data lets you build alerts on connection close patterns — for example, detecting spikes in TCP resets (ConnectionCloseReason == "peerReset") grouped by host and data center — directly in your existing log analysis tools.

For the full list of available fields, refer to WebSocket Analytics.

Cloudflare has updated Logpush datasets:

• Gateway DNS (added): AppliedMaxTTL and UpstreamRecordTTLs.
• Gateway HTTP (added): Warnings.
• HTTP requests (added): CacheLockWaitedMs.

For the complete field definitions for each dataset, refer to Logpush datasets.

You can now assign granular, resource-scoped roles for Cloudflare Gateway firewall policies and Zero Trust lists. Administrators can delegate access to specific policy types or list management without granting account-wide or product-wide control.

When you add a member or create a permission policy, the following resource-scoped roles are now available:

These roles allow you to:

• Grant a network engineer write access to Network policies only, without exposing DNS or HTTP policy configuration.
• Allow a security analyst to view all Gateway policies in read-only mode for auditing purposes.
• Delegate list management to a team that maintains block and allow lists without giving them access to policy configuration.

You can also now assign Resource-scoped roles. These roles are complementary to existing account-level roles, and allow you to grant access to a specific resource, like an individual Gateway policy or Cloudflare One list. Existing account-level roles continue to work. A member with the Cloudflare Gateway or Cloudflare Zero Trust role retains full access to all Gateway resources. This ensures backward compatibility for existing automation and API tokens.

• Review the resource-scoped roles on the Cloudflare role reference.
• Learn how to create permission policies that use these roles.

Cloudflare Logpush now supports firewall events as an account-scoped dataset. Configure a single Logpush job at the account level to receive firewall events for every zone in the account, instead of creating and maintaining a separate job per zone.

The dataset includes a new ZoneName field so you can identify which zone each event came from when consuming logs in your downstream pipeline.

• A new account-scoped firewall_events dataset, configurable via the Logpush API or the Cloudflare dashboard.
• The same fields and filter expressions supported by the existing zone-scoped firewall events dataset, plus the new ZoneName field.
• Support for all existing Logpush destinations.

You can now search API tokens by name, making it easier to find specific tokens across large token lists without manually paginating.

• Dashboard search: Both account API tokens ↗ and user API tokens ↗ pages now include a search bar. Type a name to filter results.
• API search support: The /user/tokens and /accounts/{account_id}/tokens endpoints now accept a name query parameter to filter tokens by name.

For more information, refer to Create an API token and Account API tokens.

You can now, as an Organization Super Administrator, view organization-level audit logs in the Cloudflare dashboard, in addition to the existing API access.

Organization audit logs help you monitor activity across your organization. You can see who performed an action, what changed, when it happened, how it was performed, and whether it succeeded or failed.

You can filter and search logs by actor, action, result, resource, request details, and timestamp. Use these logs to troubleshoot changes, investigate unexpected access, and support security or compliance workflows.

If you are viewing account-level audit logs and the account belongs to an organization where you are an Organization Super Administrator, select View Organization Audit Logs to open the parent organization's audit logs.

To get started, go to Organizations, select your organization, then go to Manage Organization > Audit Logs.

For more information, refer to the Audit Logs documentation.

Cloudflare has updated Logpush datasets:

• WebSocket Analytics: A new dataset with fields including BytesReceivedClient, BytesReceivedOrigin, BytesSentClient, BytesSentOrigin, ClientASN, ClientIP, ClientRequestHost, ClientRequestPath, ClientRequestUserAgent, ColoCode, ConnectionCloseReason, ConnectionCloseSource, ConnectionID, ConnectionTransportCloseCode, EdgeEndTimestamp, EdgeStartTimestamp, and RayID.

• Firewall events (added): ZoneName. The Firewall events dataset is now also available for account-scope Logpush, in addition to the existing zone scope.
• Email Security Alerts (added): BCC, DKIMResult, DMARCPolicy, DMARCResult, and SPFResult.

For the complete field definitions for each dataset, refer to Logpush datasets.

The Routes page in the Cloudflare dashboard now shows the routes across all of your connectors — Cloudflare Mesh and Cloudflare Tunnel routes alongside Cloudflare WAN and Magic Transit static routes — in a single table, instead of a separate routes view per product.

From the unified Routes page you can:

• Visualize your network with an interactive map that shows how your destinations flow through to your connectors — including equal-cost multi-path (ECMP) routes where the same prefix is served by several connectors. Select a node to filter the table down to the routes behind it.
• See every route in one table, with its destination, type, connector, priority, and source, and filter or sort to find what you need.
• Create, edit, and delete routes of any supported type without leaving the page. When adding a Cloudflare WAN or Magic Transit static route, you now pick the next hop by connector name instead of typing its IP.
• Manage virtual networks from a dedicated tab.
• Test a route to see which connector and next hop a destination resolves to before you commit a change.

To find it, go to Networking > Routes in the dashboard sidebar.

Your existing routes, APIs, and configurations are unchanged — this is a dashboard experience that brings them together in one place. Learn how to add routes and manage virtual networks.

You can now configure advanced Pay Per Crawl settings for your zone, including:

• Disable Pay Per Crawl by URI pattern using Configuration Rules to offer free access to specific pages while charging for others.
• Dynamic pricing by having your origin return a crawler-price response header, or by using a Cloudflare Worker to set prices based on request properties.

When dynamic pricing is enabled, Pay Per Crawl adds a cf-pay-per-crawl request header to origin requests so your origin or Worker can determine the appropriate price.

Refer to the Advanced configuration documentation for details.

Cloudflare's Terraform v5 Provider makes it easy for developers to manage their Cloudflare infrastructure using a configuration as code approach. It releases every 2-3 weeks ↗ to ensure that you can always manage the latest features in the platform. This week, we launched Terraform v5.20.0, which adds 24 new resources, bumps the underlying Go SDK to cloudflare-go v7, and includes a range of bug fixes and state upgraders based on community feedback.

• cloudflare_ai_search_namespace: Manage AI Search namespaces
• cloudflare_custom_csr: Manage custom certificate signing requests
• cloudflare_dls_prefix_binding: Manage DLS regional service prefix bindings
• cloudflare_flagship_app: Manage Flagship feature flag apps
• cloudflare_flagship_flag: Manage Flagship feature flags
• cloudflare_google_tag_gateway: Manage Google Tag Gateway
• cloudflare_load_balancer_monitor_group: Manage load balancer monitor groups
• cloudflare_oauth_client: Manage IAM OAuth clients
• cloudflare_origin_cloud_region: Manage origin cloud regions (v2 endpoints)
• cloudflare_secrets_store: Manage Secrets Store instances
• cloudflare_secrets_store_secret: Manage Secrets Store secrets
• cloudflare_share: Manage resource shares
• cloudflare_share_recipient: Manage share recipients
• cloudflare_share_resource: Manage shared resources
• cloudflare_zero_trust_device_deployment_groups: Manage Zero Trust device deployment groups
• cloudflare_zero_trust_dlp_data_class: Manage DLP data classes
• cloudflare_zero_trust_dlp_data_tag: Manage DLP data tags
• cloudflare_zero_trust_dlp_data_tag_category: Manage DLP data tag categories
• cloudflare_zero_trust_dlp_sensitivity_group: Manage DLP sensitivity groups
• cloudflare_zero_trust_dlp_sensitivity_level: Manage DLP sensitivity levels
• cloudflare_zero_trust_dlp_sensitivity_level_order: Manage DLP sensitivity level ordering
• cloudflare_zero_trust_resource_library_application: Manage Zero Trust resource library applications
• cloudflare_zero_trust_resource_library_category: Manage Zero Trust resource library categories
• cloudflare_zero_trust_tunnel_warp_connector_config: Manage WARP connector tunnel configurations

• cache: add create (POST) method for smart_tiered_cache
• cache: update OPCR config to v2 endpoints
• dlp: promote classification Stainless config to main
• dlp: add custom prompt topics endpoint
• email_security_block_sender: state upgrader for v4 to v5 migration
• email_security_impersonation_registry: state upgrader for v4 to v5 migration
• email_security_trusted_domains: state upgrader for v4 to v5 migration
• snippets: add Terraform id_property annotations for snippet and snippet_rules
• bump Go SDK to cloudflare-go v7

• account_member: missing upgrade path from v5.0–v5.15
• authenticated_origin_pulls_settings: nil pointer panic
• bot_management: restore content_bots_protection handling in model.go
• dns_record: prevent FQDN normalization from swallowing name shortening changes
• list: nullify empty nested objects to prevent inconsistent result after apply
• load_balancer_pool: accept early-v5 object-shape state at schema_version=0
• load_balancer_pool: add UseStateForUnknown for load_shedding attribute to prevent drift
• r2_custom_domain: restore degraded-response handling in resource.go
• regional_hostname: update cloudflare-go imports from v6 to v7
• secrets_store: fix model/schema parity and guard acceptance tests
• spectrum_application: accept early-v5 object-shape state at schema_version=0
• worker: preserve observability.traces.propagation_policy across reads
• worker: add propagation_policy to observability defaults
• worker_version: restore handwritten D1 database_id handling
• workers_custom_domain: missing CertId field in state migration
• workers_script: restore annotations Read workaround stripped by codegen
• zero_trust_access_identity_provider: change read_only from computed to optional
• zero_trust_access_identity_provider: add UseStateForUnknown to SAML-only config fields
• zero_trust_access_identity_provider: use UseNonNullStateForUnknown on scim_config fields
• zero_trust_access_policy: populate account_id when migrating zone-scoped v4 state
• zero_trust_access_policy: missing common_names transform in migration
• gracefully handle nil pointer dereference when config has attributes_flat during migration
• set initial schema version to 500 for all new resources

Extracted MoveState nil guard into shared helper

• Terraform Provider ↗
• Version 5 Migration Guide ↗
• Documentation on using Terraform with Cloudflare
• List of stabilized resources ↗

Pay-as-you-go customers can now view billable usage and create budget alerts directly from the product overview pages for Workers & Pages, D1, R2, Workers KV, Queues, Vectorize, Durable Objects, and Containers. A new sidebar widget shows current-period spend and the billing cycle date range, alongside a button to create a budget alert.

The widget pulls from the same data as the Billable Usage dashboard and aligns to your billing cycle (or the current day on Free plans), so the numbers match your invoice. Enterprise contract accounts are not yet supported.

Selecting Create budget alert opens the budget alert flow inline so you can set a dollar threshold in the same place you are reviewing usage. Budget alerts apply to your total account-level spend across all products, not just the product page you create them from.

For more information, refer to the Usage-based billing documentation.

Today we are launching self-managed OAuth, enabling developers to build third-party applications that integrate with Cloudflare via OAuth. This provides a more secure, user-friendly, and manageable alternative to API tokens.

OAuth lets third-party applications act on behalf of a user to access their Cloudflare account. For example, after a user grants consent, Wrangler can deploy Workers into that account.

Cloudflare Developers can now create and manage their own OAuth applications to integrate with Cloudflare.

To create an application, go to Manage account > OAuth clients in your account on the Cloudflare dashboard.

If you have used an API token to call Cloudflare APIs, OAuth client scopes will look familiar. Select only the scopes your application needs during application creation, and include that scope list when sending users to Cloudflare for consent.

Users can review the requested scopes before they consent.

Applications start with private visibility. Private applications can only be used by members of the account where the application was created.

To make an application available to any Cloudflare user, complete the prerequisites for public visibility.

For more information, refer to client visibility.

Before an application can be made public, you must verify the client domain. Domain verification helps users confirm that the application owner controls the domain shown on the consent page.

After verification, users see a verified badge on the consent page.

For more information, refer to domain verification.

For more information, refer to OAuth clients.

Cloudflare has updated Logpush datasets:

• Turnstile Events: A new dataset with fields including ASN, Action, BrowserMajor, BrowserName, ClientIP, CountryCode, EventType, Hostname, OSMajor, OSName, Sitekey, Timestamp, and UserAgent.

For the complete field definitions for each dataset, refer to Logpush datasets.