Changelog

When AI systems request pages from any website that uses Cloudflare and has Markdown for Agents enabled, they can express the preference for text/markdown in the request: our network will automatically and efficiently convert the HTML to markdown, when possible, on the fly.

This release adds the following improvements:

• The origin response limit was raised from 1 MB to 2 MB (2,097,152 bytes).
• We no longer require the origin to send the content-length header.
• We now support content encoded responses from the origin.

If you haven’t enabled automatic Markdown conversion yet, visit the AI Crawl Control ↗ section of the Cloudflare dashboard and enable Markdown for Agents.

Refer to our developer documentation for more details.

Fine-grained permissions for Access policies and Access service tokens are available. These new resource-scoped roles expand the existing RBAC model, enabling administrators to grant permissions scoped to individual resources.

• Cloudflare Access policy admin: Can edit a specific Access policy in an account.
• Cloudflare Access service token admin: Can edit a specific Access service token in an account.

These roles complement the existing resource-scoped roles for Access applications, identity providers, and infrastructure targets.

For more information:

• Resource-scoped roles
• Role scopes

Disclaimer: Please note that v5.0.0-beta.1 is in Beta and we are still testing it for stability.

Full Changelog: v4.3.1...v5.0.0-beta.1 ↗

In this release, you'll see a large number of breaking changes. This is primarily due to a change in OpenAPI definitions, which our libraries are based off of, and codegen updates that we rely on to read those OpenAPI definitions and produce our SDK libraries. As the codegen is always evolving and improving, so are our code bases.

There may be changes that are not captured in this changelog. Feel free to open an issue to report any inaccuracies, and we will make sure it gets into the changelog before the v5.0.0 release.

Most of the breaking changes below are caused by improvements to the accuracy of the base OpenAPI schemas, which sometimes translates to breaking changes in downstream clients that depend on those schemas.

Please ensure you read through the list of changes below and the migration guide before moving to this version - this will help you understand any down or upstream issues it may cause to your environments.

The following resources have breaking changes. See the v5 Migration Guide ↗ for detailed migration instructions.

• abusereports
• acm.totaltls
• apigateway.configurations
• cloudforceone.threatevents
• d1.database
• intel.indicatorfeeds
• logpush.edge
• origintlsclientauth.hostnames
• queues.consumers
• radar.bgp
• rulesets.rules
• schemavalidation.schemas
• snippets
• zerotrust.dlp
• zerotrust.networks

• abusereports - Abuse report management
• abusereports.mitigations - Abuse report mitigation actions
• ai.tomarkdown - AI-powered markdown conversion
• aigateway.dynamicrouting - AI Gateway dynamic routing configuration
• aigateway.providerconfigs - AI Gateway provider configurations
• aisearch - AI-powered search functionality
• aisearch.instances - AI Search instance management
• aisearch.tokens - AI Search authentication tokens
• alerting.silences - Alert silence management
• brandprotection.logomatches - Brand protection logo match detection
• brandprotection.logos - Brand protection logo management
• brandprotection.matches - Brand protection match results
• brandprotection.queries - Brand protection query management
• cloudforceone.binarystorage - CloudForce One binary storage
• connectivity.directory - Connectivity directory services
• d1.database - D1 database management
• diagnostics.endpointhealthchecks - Endpoint health check diagnostics
• fraud - Fraud detection and prevention
• iam.sso - IAM Single Sign-On configuration
• loadbalancers.monitorgroups - Load balancer monitor groups
• organizations - Organization management
• organizations.organizationprofile - Organization profile settings
• origintlsclientauth.hostnamecertificates - Origin TLS client auth hostname certificates
• origintlsclientauth.hostnames - Origin TLS client auth hostnames
• origintlsclientauth.zonecertificates - Origin TLS client auth zone certificates
• pipelines - Data pipeline management
• pipelines.sinks - Pipeline sink configurations
• pipelines.streams - Pipeline stream configurations
• queues.subscriptions - Queue subscription management
• r2datacatalog - R2 Data Catalog integration
• r2datacatalog.credentials - R2 Data Catalog credentials
• r2datacatalog.maintenanceconfigs - R2 Data Catalog maintenance configurations
• r2datacatalog.namespaces - R2 Data Catalog namespaces
• radar.bots - Radar bot analytics
• radar.ct - Radar certificate transparency data
• radar.geolocations - Radar geolocation data
• realtimekit.activesession - Real-time Kit active session management
• realtimekit.analytics - Real-time Kit analytics
• realtimekit.apps - Real-time Kit application management
• realtimekit.livestreams - Real-time Kit live streaming
• realtimekit.meetings - Real-time Kit meeting management
• realtimekit.presets - Real-time Kit preset configurations
• realtimekit.recordings - Real-time Kit recording management
• realtimekit.sessions - Real-time Kit session management
• realtimekit.webhooks - Real-time Kit webhook configurations
• tokenvalidation.configuration - Token validation configuration
• tokenvalidation.rules - Token validation rules
• workers.beta - Workers beta features

• edit()
• update()

• list()

• create()
• get()
• update()

• scan_list()
• scan_review()
• scan_trigger()

• create()
• delete()
• list()

• get()

• list()

• summary()
• timeseries()
• timeseries_groups()

• changes()
• snapshot()

• delete()

• create()
• delete()
• edit()
• get()
• list()

• Type inference improvements: Allow Pyright to properly infer TypedDict types within SequenceNotStr
• Type completeness: Add missing types to method arguments and response models
• Pydantic compatibility: Ensure compatibility with Pydantic versions prior to 2.8.0 when using additional fields

• Multipart form data: Correctly handle sending multipart/form-data requests with JSON data
• Header handling: Do not send headers with default values set to omit
• GET request headers: Don't send Content-Type header on GET requests
• Response body model accuracy: Broad improvements to the correctness of models

• Discriminated unions: Correctly handle nested discriminated unions in response parsing
• Extra field types: Parse extra field types correctly
• Empty metadata: Ignore empty metadata fields during parsing
• Singularization rules: Update resource name singularization rules for better consistency

Cloudflare's network now supports real-time content conversion at the source, for enabled zones using content negotiation ↗ headers. When AI systems request pages from any website that uses Cloudflare and has Markdown for Agents enabled, they can express the preference for text/markdown in the request: our network will automatically and efficiently convert the HTML to markdown, when possible, on the fly.

Here is a curl example with the Accept negotiation header requesting this page from our developer documentation:

curl https://developers.cloudflare.com/fundamentals/reference/markdown-for-agents/ \
  -H "Accept: text/markdown"

The response to this request is now formatted in markdown:

HTTP/2 200
date: Wed, 11 Feb 2026 11:44:48 GMT
content-type: text/markdown; charset=utf-8
content-length: 2899
vary: accept
x-markdown-tokens: 725
content-signal: ai-train=yes, search=yes, ai-input=yes

---
title: Markdown for Agents · Cloudflare Agents docs
---

## What is Markdown for Agents

Markdown has quickly become the lingua franca for agents and AI systems
as a whole. The format’s explicit structure makes it ideal for AI processing,
ultimately resulting in better results while minimizing token waste.
...

Refer to our developer documentation and our blog announcement ↗ for more details.

In January 2025, we announced the launch of the new Terraform v5 Provider. We greatly appreciate the proactive engagement and valuable feedback from the Cloudflare community following the v5 release. In response, we have established a consistent and rapid 2-3 week cadence ↗ for releasing targeted improvements, demonstrating our commitment to stability and reliability.

With the help of the community, we have a growing number of resources that we have marked as stable ↗, with that list continuing to grow with every release. The most used resources ↗ are on track to be stable by the end of March 2026, when we will also be releasing a new migration tool to help you migrate from v4 to v5 with ease.

This release brings new capabilities for AI Search, enhanced Workers Script placement controls, and numerous bug fixes based on community feedback. We also begun laying foundational work for improving the v4 to v5 migration process. Stay tuned for more details as we approach the March 2026 release timeline.

Thank you for continuing to raise issues. They make our provider stronger and help us build products that reflect your needs.

• ai_search_instance: add data source for querying AI Search instances
• ai_search_token: add data source for querying AI Search tokens
• account: add support for tenant unit management with new unit field
• account: add automatic mapping from managed_by.parent_org_id to unit.id
• authenticated_origin_pulls_certificate: add data source for querying authenticated origin pull certificates
• authenticated_origin_pulls_hostname_certificate: add data source for querying hostname-specific authenticated origin pull certificates
• authenticated_origin_pulls_settings: add data source for querying authenticated origin pull settings
• workers_kv: add value field to data source to retrieve KV values directly
• workers_script: add script field to data source to retrieve script content
• workers_script: add support for simple rate limit binding
• workers_script: add support for targeted placement mode with placement.target array for specifying placement targets (region, hostname, host)
• workers_script: add placement_mode and placement_status computed fields
• zero_trust_dex_test: add data source with filter support for finding specific tests
• zero_trust_dlp_predefined_profile: add enabled_entries field for flexible entry management

• account: map managed_by.parent_org_id to unit.id in unmarshall and add acceptance tests
• authenticated_origin_pulls_certificate: add certificate normalization to prevent drift
• authenticated_origin_pulls: handle array response and implement full lifecycle
• authenticated_origin_pulls_hostname_certificate: fix resource and tests
• cloudforce_one_request_message: use correct request_id field instead of id in API calls
• dns_zone_transfers_incoming: use correct zone_id field instead of id in API calls
• dns_zone_transfers_outgoing: use correct zone_id field instead of id in API calls
• email_routing_settings: use correct zone_id field instead of id in API calls
• hyperdrive_config: add proper handling for write-only fields to prevent state drift
• hyperdrive_config: add normalization for empty mtls objects to prevent unnecessary diffs
• magic_network_monitoring_rule: use correct account_id field instead of id in API calls
• mtls_certificates: fix resource and test
• pages_project: revert build_config to computed optional
• stream_key: use correct account_id field instead of id in API calls
• total_tls: use upsert pattern for singleton zone setting
• waiting_room_rules: use correct waiting_room_id field instead of id in API calls
• workers_script: add support for placement mode/status
• zero_trust_access_application: update v4 version on migration tests
• zero_trust_device_posture_rule: update tests to match API
• zero_trust_dlp_integration_entry: use correct entry_id field instead of id in API calls
• zero_trust_dlp_predefined_entry: use correct entry_id field instead of id in API calls
• zero_trust_organization: fix plan issues

• add state upgraders to 95+ resources to lay the foundation for replacing Grit (still under active development)
• certificate_pack: add state migration handler for SDKv2 to Framework conversion
• custom_hostname_fallback_origin: add comprehensive lifecycle test and migration support
• dns_record: add state migration handler for SDKv2 to Framework conversion
• leaked_credential_check: add import functionality and tests
• load_balancer_pool: add state migration handler with detection for v4 vs v5 format
• pages_project: add state migration handlers
• tiered_cache: add state migration handlers
• zero_trust_dlp_predefined_profile: deprecate entries field in favor of enabled_entries

• Terraform Provider ↗
• Documentation on using Terraform with Cloudflare
• List of stabilized resources ↗

You can now set the timezone in the Cloudflare dashboard as Coordinated Universal Time (UTC) or your browser or system's timezone.

Unless otherwise specified in the user interface, all dates and times in the Cloudflare dashboard are now displayed in the selected timezone.

You can change the timezone setting from the user profile dropdown.

The page will reload to apply the new timezone setting.

In an effort to improve overall user security, users without 2FA will be prompted upon login to enroll in email 2FA. This will improve user security posture while minimizing friction. Users without email 2FA enabled will see a prompt to secure their account with additional factors upon logging in. Enrolling in 2FA remains optional, but strongly encouraged as it is the best way to prevent account takeovers.

We also made changes to existing 2FA screens to improve the user experience. Now we have distinct experiences for each 2FA factor type, reflective of the way that factor works.

• Configure Email Two Factor Authentication

Disclaimer: Please note that v6.0.0-beta.1 is in Beta and we are still testing it for stability.

Full Changelog: v5.2.0...v6.0.0-beta.1 ↗

In this release, you'll see a large number of breaking changes. This is primarily due to a change in OpenAPI definitions, which our libraries are based off of, and codegen updates that we rely on to read those OpenAPI definitions and produce our SDK libraries. As the codegen is always evolving and improving, so are our code bases.

Some breaking changes were introduced due to bug fixes, also listed below.

Please ensure you read through the list of changes below before moving to this version - this will help you understand any down or upstream issues it may cause to your environments.

• BGPPrefixCreateParams.cidr: optional → required
• PrefixCreateParams.asn: number | null → number
• PrefixCreateParams.loa_document_id: required → optional
• ServiceBindingCreateParams.cidr: optional → required
• ServiceBindingCreateParams.service_id: optional → required

• ConfigurationUpdateResponse removed
• PublicSchema → OldPublicSchema
• SchemaUpload → UserSchemaCreateResponse
• ConfigurationUpdateParams.properties removed; use normalize

• ThreatEventBulkCreateResponse: number → complex object with counts and errors

• DatabaseQueryParams: simple interface → union type (D1SingleQuery | MultipleQueries)
• DatabaseRawParams: same change
• Supports batch queries via batch array

All record type interfaces renamed from *Record to short names:

• RecordResponse.ARecord → RecordResponse.A
• RecordResponse.AAAARecord → RecordResponse.AAAA
• RecordResponse.CNAMERecord → RecordResponse.CNAME
• RecordResponse.MXRecord → RecordResponse.MX
• RecordResponse.NSRecord → RecordResponse.NS
• RecordResponse.PTRRecord → RecordResponse.PTR
• RecordResponse.TXTRecord → RecordResponse.TXT
• RecordResponse.CAARecord → RecordResponse.CAA
• RecordResponse.CERTRecord → RecordResponse.CERT
• RecordResponse.DNSKEYRecord → RecordResponse.DNSKEY
• RecordResponse.DSRecord → RecordResponse.DS
• RecordResponse.HTTPSRecord → RecordResponse.HTTPS
• RecordResponse.LOCRecord → RecordResponse.LOC
• RecordResponse.NAPTRRecord → RecordResponse.NAPTR
• RecordResponse.SMIMEARecord → RecordResponse.SMIMEA
• RecordResponse.SRVRecord → RecordResponse.SRV
• RecordResponse.SSHFPRecord → RecordResponse.SSHFP
• RecordResponse.SVCBRecord → RecordResponse.SVCB
• RecordResponse.TLSARecord → RecordResponse.TLSA
• RecordResponse.URIRecord → RecordResponse.URI
• RecordResponse.OpenpgpkeyRecord → RecordResponse.Openpgpkey

• ResourceGroupCreateResponse.scope: optional single → required array
• ResourceGroupCreateResponse.id: optional → required

• OriginCACertificateCreateParams.csr: optional → required
• OriginCACertificateCreateParams.hostnames: optional → required
• OriginCACertificateCreateParams.request_type: optional → required

• Renamed: DeploymentsSinglePage → DeploymentListResponsesV4PagePaginationArray
• Domain response fields: many optional → required

• Entire v0 API deprecated; use v1 methods (createV1, listV1, etc.)
• New sub-resources: Sinks, Streams

• EventNotificationUpdateParams.rules: optional → required
• Super Slurper: bucket, secret now required in source params

• dataSource: string → typed enum (23 values)
• eventType: string → typed enum (6 values)
• V2 methods require dimension parameter (breaking signature change)

• Removed: status_message field from all recipient response types

• Consolidated SchemaCreateResponse, SchemaListResponse, SchemaEditResponse, SchemaGetResponse → PublicSchema
• Renamed: SchemaListResponsesV4PagePaginationArray → PublicSchemasV4PagePaginationArray

• Renamed union members: AppListResponse.UnionMember0 → SpectrumConfigAppConfig
• Renamed union members: AppListResponse.UnionMember1 → SpectrumConfigPaygoAppConfig

• Removed: WorkersBindingKindTailConsumer type (all occurrences)
• Renamed: ScriptsSinglePage → ScriptListResponsesSinglePage
• Removed: DeploymentsSinglePage

• datasets.create(), update(), get() return types changed
• PredefinedGetResponse union members renamed to UnionMember0-5

• Removed: CloudflaredCreateResponse, CloudflaredListResponse, CloudflaredDeleteResponse, CloudflaredEditResponse, CloudflaredGetResponse
• Removed: CloudflaredListResponsesV4PagePaginationArray

• Reports: create, list, get
• Mitigations: sub-resource for abuse mitigations

• Instances: create, update, list, delete, read, stats
• Items: list, get
• Jobs: create, list, get, logs
• Tokens: create, update, list, delete, read

• Directory Services: create, update, list, delete, get
• Supports IPv4, IPv6, dual-stack, and hostname configurations

• Organizations: create, update, list, delete, get
• OrganizationProfile: update, get
• Hierarchical organization support with parent/child relationships

• Catalog: list, enable, disable, get
• Credentials: create
• MaintenanceConfigs: update, get
• Namespaces: list
• Tables: list, maintenance config management
• Apache Iceberg integration

• Apps: get, post
• Meetings: create, get, participant management
• Livestreams: 10+ methods for streaming
• Recordings: start, pause, stop, get
• Sessions: transcripts, summaries, chat
• Webhooks: full CRUD
• ActiveSession: polls, kick participants
• Analytics: organization analytics

• Configuration: create, list, delete, edit, get
• Credentials: update
• Rules: create, list, delete, bulkCreate, bulkEdit, edit, get
• JWT validation with RS256/384/512, PS256/384/512, ES256, ES384

• create, update, list, delete, get

• create, update, list, delete, get, beginVerification

• Sinks: create, list, delete, get
• Streams: create, update, list, delete, get

• Portals: create, update, list, delete, read
• Servers: create, update, list, delete, read, sync

• managed_by field with parent_org_id, parent_org_name

• auto_generated field on LOADocumentCreateResponse

• delegate_loa_creation, irr_validation_state, ownership_validation_state, ownership_validation_token, rpki_validation_state

• Added toMarkdown.supported() method to get all supported conversion formats

• zdr field added to all responses and params

• New alert type: abuse_report_alert
• type field added to PolicyFilter

• ContentCreateParams: refined to discriminated union (Variant0 | Variant1)
• Split into URL-based and HTML-based parameter variants for better type safety

• reactivate parameter in edit

• ThreatEventCreateParams.indicatorType: required → optional
• hasChildren field added to all threat event response types
• datasetIds query parameter on AttackerListParams, CategoryListParams, TargetIndustryListParams
• categoryUuid field on TagCreateResponse
• indicators array for multi-indicator support per event
• uuid and preserveUuid fields for UUID preservation in bulk create
• format query parameter ('json' | 'stix2') on ThreatEventListParams
• createdAt, datasetId fields on ThreatEventEditParams

• Added create(), update(), get() methods

• New page types: basic_challenge, under_attack, waf_challenge

• served_by_colo - colo that handled query
• jurisdiction - 'eu' | 'fedramp'
• Time Travel (client.d1.database.timeTravel): getBookmark(), restore() - point-in-time recovery

• New fields on InvestigateListResponse/InvestigateGetResponse: envelope_from, envelope_to, postfix_id_outbound, replyto
• New detection classification: 'outbound_ndr'
• Enhanced Finding interface with attachment, detection, field, portion, reason, score
• Added cursor query parameter to InvestigateListParams

• New list types: CATEGORY, LOCATION, DEVICE

• New issue type: 'configuration_suggestion'
• payload field: unknown → typed Payload interface with detection_method, zone_tag

• Added detections.get() method

• New datasets: dex_application_tests, dex_device_state_events, ipsec_logs, warp_config_changes, warp_toggle_changes

• Monitor.port: number → number | null
• Pool.load_shedding: LoadShedding → LoadShedding | null
• Pool.origin_steering: OriginSteering → OriginSteering | null

• license_key field on connectors
• provision_license parameter for auto-provisioning
• IPSec: custom_remote_identities with FQDN support
• Snapshots: Bond interface, probed_mtu field

• New response types: ProjectCreateResponse, ProjectListResponse, ProjectEditResponse, ProjectGetResponse
• Deployment methods return specific response types instead of generic Deployment

• Added subscriptions.get() method
• Enhanced SubscriptionGetResponse with typed event source interfaces
• New event source types: Images, KV, R2, Vectorize, Workers AI, Workers Builds, Workflows

• Sippy: new provider s3 (S3-compatible endpoints)
• Sippy: bucketUrl field for S3-compatible sources
• Super Slurper: keys field on source response schemas (specify specific keys to migrate)
• Super Slurper: pathPrefix field on source schemas
• Super Slurper: region field on S3 source params

• Added geolocations.list(), geolocations.get() methods
• Added V2 dimension-based methods (summaryV2, timeseriesGroupsV2) to radar sub-resources

• Added terminal boolean field to Resource Error interfaces

• Added id field to ItemDeleteParams.Item

• New buffering fields on SetConfigRule: request_body_buffering, response_body_buffering

• New scopes: 'dex', 'access' (in addition to 'workers', 'ai_gateway')

• Response types now proper interfaces (was unknown)
• Fields now required: id, certificates, hosts, status, type

• payload field: unknown → typed Payload interface with detection_method, zone_tag

• Added: CloudflareTunnelsV4PagePaginationArray pagination class

• Added subdomains.delete() method
• Worker.references - track external dependencies (domains, Durable Objects, queues)
• Worker.startup_time_ms - startup timing
• Script.observability - observability settings with logging
• Script.tag, Script.tags - immutable ID and tags
• Placement: support for region, hostname, host-based placement
• tags, tail_consumers now accept | null
• Telemetry: traces field, $containers event info, durableObjectId, transactionName, abr_level fields

• ScriptUpdateResponse: new fields entry_point, observability, tag, tags
• placement field now union of 4 variants (smart mode, region, hostname, host)
• tags, tail_consumers now nullable
• TagUpdateParams.body now accepts null

• instance_retention: unknown → typed InstanceRetention interface with error_retention, success_retention
• New status option: 'restart' added to StatusEditParams.status

• External emergency disconnect settings (4 new fields)
• antivirus device posture check type
• os_version_extra documentation improvements

• New response types: SubscriptionCreateResponse, SubscriptionUpdateResponse, SubscriptionGetResponse

• New ApplicationType values: 'mcp', 'mcp_portal', 'proxy_endpoint'
• New destination type: ViaMcpServerPortalDestination for MCP server access

• Added rules.listTenant() method

• ProxyEndpoint: interface → discriminated union (ZeroTrustGatewayProxyEndpointIP | ZeroTrustGatewayProxyEndpointIdentity)
• ProxyEndpointCreateParams: interface → union type
• Added kind field: 'ip' | 'identity'

• WARPConnector*Response: union type → interface

• API Gateway: UserSchemas, Settings, SchemaValidation resources
• Audit Logs: auditLogId.not (use id.not)
• CloudforceOne: ThreatEvents.get(), IndicatorTypes.list()
• Devices: public_ip field (use DEX API)
• Email Security: item_count field in Move responses
• Pipelines: v0 methods (use v1)
• Radar: old summary() and timeseriesGroups() methods (use V2)
• Rulesets: disable_apps, mirage fields
• WARP Connector: connections field
• Workers: environment parameter in Domains
• Zones: ResponseBuffering page rule

• mcp: correct code tool API endpoint (599703c ↗)
• mcp: return correct lines on typescript errors (5d6f999 ↗)
• organization_profile: fix bad reference (d84ea77 ↗)
• schema_validation: correctly reflect model to openapi mapping (bb86151 ↗)
• workers: fix tests (2ee37f7 ↗)

• Added deprecation notices with migration paths
• api_gateway: deprecate API Shield Schema Validation resources (8a4b20f ↗)
• Improved JSDoc examples across all resources
• workers: expose subdomain delete documentation (4f7cc1f ↗)

In January 2025, we announced the launch of the new Terraform v5 Provider. We greatly appreciate the proactive engagement and valuable feedback from the Cloudflare community following the v5 release. In response, we've established a consistent and rapid 2-3 week cadence ↗ for releasing targeted improvements, demonstrating our commitment to stability and reliability.

With the help of the community, we have a growing number of resources that we have marked as stable ↗, with that list continuing to grow with every release. The most used resources ↗ are on track to be stable by the end of March 2026, when we will also be releasing a new migration tool to you migrate from v4 to v5 with ease.

Thank you for continuing to raise issues. They make our provider stronger and help us build products that reflect your needs.

This release includes bug fixes, the stabilization of even more popular resources, and more.

• custom_pages: add "waf_challenge" as new supported error page type identifier in both resource and data source schemas
• list: enhance CIDR validator to check for normalized CIDR notation requiring network address for IPv4 and IPv6
• magic_wan_gre_tunnel: add automatic_return_routing attribute for automatic routing control
• magic_wan_gre_tunnel: add BGP configuration support with new BGP model attribute
• magic_wan_gre_tunnel: add bgp_status computed attribute for BGP connection status information
• magic_wan_gre_tunnel: enhance schema with BGP-related attributes and validators
• magic_wan_ipsec_tunnel: add automatic_return_routing attribute for automatic routing control
• magic_wan_ipsec_tunnel: add BGP configuration support with new BGP model attribute
• magic_wan_ipsec_tunnel: add bgp_status computed attribute for BGP connection status information
• magic_wan_ipsec_tunnel: add custom_remote_identities attribute for custom identity configuration
• magic_wan_ipsec_tunnel: enhance schema with BGP and identity-related attributes
• ruleset: add request body buffering support
• ruleset: enhance ruleset data source with additional configuration options
• workers_script: add observability logs attributes to list data source model
• workers_script: enhance list data source schema with additional configuration options

• account_member: fix resource importability issues
• dns_record: remove unnecessary fmt.Sprintf wrapper around LoadTestCase call in test configuration helper function
• load_balancer: fix session_affinity_ttl type expectations to match Float64 in initial creation and Int64 after migration
• workers_kv: handle special characters correctly in URL encoding

• account_subscription: update schema description for rate_plan.sets attribute to clarify it returns an array of strings
• api_shield: add resource-level description for API Shield management of auth ID characteristics
• api_shield: enhance auth_id_characteristics.name attribute description to include JWT token configuration format requirements
• api_shield: specify JSONPath expression format for JWT claim locations
• hyperdrive_config: add description attribute to name attribute explaining its purpose in dashboard and API identification
• hyperdrive_config: apply description improvements across resource, data source, and list data source schemas
• hyperdrive_config: improve schema descriptions for cache settings to clarify default values
• hyperdrive_config: update port description to clarify defaults for different database types

• Terraform Provider ↗
• Documentation on using Terraform with Cloudflare
• List of stabilized resources ↗

Cloudflare now provides more accurate visibility into HTTP/3 client request cancellations, giving you better insight into real client behavior and reducing unnecessary load on your origins.

Previously, when an HTTP/3 client cancelled a request, the cancellation was not always actioned immediately. This meant requests could continue through the CDN — potentially all the way to your origin — even after the client had abandoned them. In these cases, logs would show the upstream response status (such as 200 or a timeout-related code) rather than reflecting the client cancellation.

Now, Cloudflare terminates cancelled HTTP/3 requests immediately and accurately logs them with a 499 status code.

When HTTP/3 clients cancel requests, Cloudflare now immediately reflects this in your logs with a 499 status code. This gives you:

• More accurate traffic analysis: Understand exactly when and how often clients cancel requests.
• Clearer debugging: Distinguish between true errors and intentional client cancellations.
• Better availability metrics: Separate client-initiated cancellations from server-side issues.

Cloudflare now terminates cancelled requests faster, which means:

• Less wasted compute: Your origin no longer processes requests that clients have already abandoned.
• Lower bandwidth usage: Responses are no longer generated and transmitted for cancelled requests.
• Improved efficiency: Resources are freed up to handle active requests.

You may notice an increase in 499 status codes for HTTP/3 traffic. For HTTP/3, a 499 indicates the client cancelled the request stream ↗ before receiving a complete response — the underlying connection may remain open. This is a normal part of web traffic.

Tip: If you use 499 codes in availability calculations, consider whether client-initiated cancellations should be excluded from error rates. These typically represent normal user behavior — such as closing a browser, navigating away from a page, mobile network drops, or cancelling a download — rather than service issues.

For more information, refer to Error 499.

Earlier this year, we announced the launch of the new Terraform v5 Provider. We are aware of the high number of issues reported by the Cloudflare community related to the v5 release. We have committed to releasing improvements on a 2-3 week cadence ↗ to ensure its stability and reliability, including the v5.15 release. We have also pivoted from an issue-to-issue approach to a resource-per-resource approach ↗ - we will be focusing on specific resources to not only stabilize the resource but also ensure it is migration-friendly for those migrating from v4 to v5.

Thank you for continuing to raise issues. They make our provider stronger and help us build products that reflect your needs.

This release includes bug fixes, the stabilization of even more popular resources, and more.

• ai_search: Add AI Search endpoints (6f02adb ↗)
• certificate_pack: Ensure proper Terraform resource ID handling for path parameters in API calls (081f32a ↗)
• worker_version: Support startup_time_ms (286ab55 ↗)
• zero_trust_dlp_custom_entry: Support upload_status (7dc0fe3 ↗)
• zero_trust_dlp_entry: Support upload_status (7dc0fe3 ↗)
• zero_trust_dlp_integration_entry: Support upload_status (7dc0fe3 ↗)
• zero_trust_dlp_predefined_entry: Support upload_status (7dc0fe3 ↗)
• zero_trust_gateway_policy: Support forensic_copy (5741fd0 ↗)
• zero_trust_list: Support additional types (category, location, device) (5741fd0 ↗)

• access_rules: Add validation to prevent state drift. Ideally, we'd use Semantic Equality but since that isn't an option, this will remove a foot-gun. (4457791 ↗)
• cloudflare_pages_project: Addressing drift issues (6edffcf ↗) (3db318e ↗)
• cloudflare_worker: Can be cleanly imported (4859b52 ↗)
• cloudflare_worker: Ensure clean imports (5b525bc ↗)
• list_items: Add validation for IP List items to avoid inconsistent state (b6733dc ↗)
• zero_trust_access_application: Remove all conditions from sweeper (3197f1a ↗)
• spectrum_application: Map missing fields during spectrum resource import (#6495 ↗) (ddb4e72 ↗)

We suggest waiting to migrate to v5 while we work on stabilization. This helps with avoiding any blocking issues while the Terraform resources are actively being stabilized ↗. We will be releasing a new migration tool in March 2026 to help support v4 to v5 transitions for our most popular resources.

• Terraform Provider ↗
• Documentation on using Terraform with Cloudflare

Earlier this year, we announced the launch of the new Terraform v5 Provider. We are aware of the high number of issues reported by the Cloudflare community related to the v5 release. We have committed to releasing improvements on a 2-3 week cadence ↗ to ensure its stability and reliability, including the v5.14 release. We have also pivoted from an issue-to-issue approach to a resource-per-resource approach ↗ - we will be focusing on specific resources to not only stabilize the resource but also ensure it is migration-friendly for those migrating from v4 to v5.

Thank you for continuing to raise issues. They make our provider stronger and help us build products that reflect your needs.

This release includes bug fixes, the stabilization of even more popular resources, and more.

Resource affected: api_shield_discovery_operation

Cloudflare continuously discovers and updates API endpoints and web assets of your web applications. To improve the maintainability of these dynamic resources, we are working on reducing the need to actively engage with discovered operations.

The corresponding public API endpoint of discovered operations ↗ is not affected and will continue to be supported.

• pages_project: Add v4 -> v5 migration tests (#6506 ↗)

• account_members: Makes member policies a set (#6488 ↗)
• pages_project: Ensures non empty refresh plans (#6515 ↗)
• R2: Improves sweeper (#6512 ↗)
• workers_kv: Ignores value import state for verify (#6521 ↗)
• workers_script: No longer treats the migrations attribute as WriteOnly (#6489 ↗)
• workers_script: Resolves resource drift when worker has unmanaged secret (#6504 ↗)
• zero_trust_device_posture_rule: Preserves input.version and other fields (#6500 ↗) and (#6503 ↗)
• zero_trust_dlp_custom_profile: Adds sweepers for dlp_custom_profile
• zone_subscription|account_subscription: Adds partners_ent as valid enum for rate_plan.id (#6505 ↗)
• zone: Ensures datasource model schema parity (#6487 ↗)
• subscription: Updates import signature to accept account_id/subscription_id to import account subscription (#6510 ↗)

We suggest waiting to migrate to v5 while we work on stabilization. This helps with avoiding any blocking issues while the Terraform resources are actively being stabilized ↗. We will be releasing a new migration tool in March 2026 to help support v4 to v5 transitions for our most popular resources.

• Terraform Provider ↗
• Documentation on using Terraform with Cloudflare ↗

Earlier this year, we announced the launch of the new Terraform v5 Provider. We are aware of the high number of issues reported by the Cloudflare community related to the v5 release. We have committed to releasing improvements on a 2-3 week cadence ↗ to ensure its stability and reliability, including the v5.13 release. We have also pivoted from an issue-to-issue approach to a resource-per-resource approach ↗ - we will be focusing on specific resources to not only stabilize the resource but also ensure it is migration-friendly for those migrating from v4 to v5.

Thank you for continuing to raise issues. They make our provider stronger and help us build products that reflect your needs.

This release includes new features, new resources and data sources, bug fixes, updates to our Developer Documentation, and more.

Please be aware that there are breaking changes for the cloudflare_api_token and cloudflare_account_token resources. These changes eliminate configuration drift caused by policy ordering differences in the Cloudflare API.

For more specific information about the changes or the actions required, please see the detailed Repository changelog ↗.

• New resources and data sources added
  • cloudflare_connectivity_directory
  • cloudflare_sso_connector
  • cloudflare_universal_ssl_setting
• api_token+account_tokens: state upgrader and schema bump (#6472 ↗)
• docs: make docs explicit when a resource does not have import support
• magic_transit_connector: support self-serve license key (#6398 ↗)
• worker_version: add content_base64 support
• worker_version: boolean support for run_worker_first (#6407 ↗)
• workers_script_subdomains: add import support (#6375 ↗)
• zero_trust_access_application: add proxy_endpoint for ZT Access Application (#6453 ↗)
• zero_trust_dlp_predefined_profile: Switch DLP Predefined Profile endpoints, introduce enabled_entries attribute

• account_token: token policy order and nested resources (#6440 ↗)
• allow r2_bucket_event_notification to be applied twice without failing (#6419 ↗)
• cloudflare_worker+cloudflare_worker_version: import for the resources (#6357 ↗)
• dns_record: inconsistent apply error (#6452 ↗)
• pages_domain: resource tests (#6338 ↗)
• pages_project: unintended resource state drift (#6377 ↗)
• queue_consumer: id population (#6181 ↗)
• workers_kv: multipart request (#6367 ↗)
• workers_kv: updating workers metadata attribute to be read from endpoint (#6386 ↗)
• workers_script_subdomain: add note to cloudflare_workers_script_subdomain about redundancy with cloudflare_worker (#6383 ↗)
• workers_script: allow config.run_worker_first to accept list input
• zero_trust_device_custom_profile_local_domain_fallback: drift issues (#6365 ↗)
• zero_trust_device_custom_profile: resolve drift issues (#6364 ↗)
• zero_trust_dex_test: correct configurability for 'targeted' attribute to fix drift
• zero_trust_tunnel_cloudflared_config: remove warp_routing from cloudflared_config (#6471 ↗)

We suggest holding off on migration to v5 while we work on stabilization. This help will you avoid any blocking issues while the Terraform resources are actively being stabilized. We will be releasing a new migration tool in March 2026 to help support v4 to v5 transitions for our most popular resources.

• Terraform Provider ↗
• Documentation on using Terraform with Cloudflare ↗

Two-factor authentication (2FA) is one of the best ways to protect your account from the risk of account takeover. Cloudflare has offered phishing resistant 2FA options including hardware based keys (for example, a Yubikey) and app based TOTP (time-based one-time password) options which use apps like Google or Microsoft's Authenticator app. Unfortunately, while these solutions are very secure, they can be lost if you misplace the hardware based key, or lose the phone which includes that app. The result is that users sometimes get locked out of their accounts and need to contact support.

Today, we are announcing the addition of email as a 2FA factor for all Cloudflare accounts. Email 2FA is in wide use across the industry as a least common denominator for 2FA because it is low friction, loss resistant, and still improves security over username/password login only. We also know that most commercial email providers already require 2FA, so your email address is usually well protected already.

You can now enable email 2FA on the Cloudflare dashboard:

1. Go to Profile at the top right corner.
2. Select Authentication.
3. Under Two-Factor Authentication, select Set up.

Cloudflare is critical infrastructure, and you should protect it as such. Review the following best practices and make sure you are doing your part to secure your account:

• Use a unique password for every website, including Cloudflare, and store it in a password manager like 1Password or Keeper. These services are cross-platform and simplify the process of managing secure passwords.
• Use 2FA to make it harder for an attacker to get into your account in the event your password is leaked.
• Store your backup codes securely. A password manager is the best place since it keeps the backup codes encrypted, but you can also print them and put them somewhere safe in your home.
• If you use an app to manage your 2FA keys, enable cloud backup, so that you don't lose your keys in the event you lose your phone.
• If you use a custom email domain to sign in, configure SSO.
• If you use a public email domain like Gmail or Hotmail, you can also use social login with Apple, GitHub, or Google to sign in.
• If you manage a Cloudflare account for work:
  • Have at least two administrators in case one of them unexpectedly leaves your company.
  • Use SCIM to automate permissions management for members in your Cloudflare account.

As Cloudflare's platform has grown, so has the need for precise, role-based access control. We’ve redesigned the Member Management experience in the Dashboard to help administrators more easily discover, assign, and refine permissions for specific principals.

Refreshed member invite flow

We overhauled the Invite Members UI to simplify inviting users and assigning permissions.

Refreshed Members Overview Page

We've updated the Members Overview Page to clearly display:

• Member 2FA status
• Which members hold Super Admin privileges
• API access settings per member
• Member onboarding state (accepted vs pending invite)

New Member Permission Policies Details View

We've created a new member details screen that shows all permission policies associated with a member; including policies inherited from group associations to make it easier for members to understand the effective permissions they have.

Improved Member Permission Workflow

We redesigned the permission management experience to make it faster and easier for administrators to review roles and grant access.

Account-scoped Policies Restrictions Relaxed

Previously, customers could only associate a single account-scoped policy with a member. We've relaxed this restriction, and now Administrators can now assign multiple account-scoped policies to the same member; bringing policy assignment behavior in-line with user-groups and providing greater flexibility in managing member permissions.

We're excited to announce a significant increase in the maximum header size supported by Cloudflare's Content Delivery Network (CDN). Cloudflare now supports up to 128 KB for both request and response headers.

Previously, customers were limited to a total of 32 KB for request or response headers, with a maximum of 16 KB per individual header. Larger headers could cause requests to fail with HTTP 413 (Request Header Fields Too Large) errors.

• Support for large headers: You can now utilize much larger headers, whether as a single large header up to 128 KB or split over multiple headers.
• Reduces 413 and 520 HTTP errors: This change drastically reduces the likelihood of customers encountering HTTP 413 errors from large request headers or HTTP 520 errors caused by oversized response headers, improving the overall reliability of your web applications.
• Enhanced functionality: This is especially beneficial for applications that rely on:
  • A large number of cookies.
  • Large Content-Security-Policy (CSP) response headers.
  • Advanced use cases with Cloudflare Workers that generate large response headers.

This enhancement improves compatibility with Cloudflare's CDN, enabling more use cases that previously failed due to header size limits.

To learn more and get started, refer to the Cloudflare Fundamentals documentation.

During Birthday Week, we announced that single sign-on (SSO) is available for free ↗ to everyone who signs in with a custom email domain and maintains a compatible identity provider ↗. SSO minimizes user friction around login and provides the strongest security posture available. At the time, this could only be configured using the API.

Today, we are launching a new user experience which allows users to manage their SSO configuration from within the Cloudflare dashboard. You can access this by going to Manage account > Members > Settings.

• Cloudflare dashboard SSO

The most common reason users contact Cloudflare support is lost two-factor authentication (2FA) credentials. Cloudflare supports both app-based and hardware keys for 2FA, but you could lose access to your account if you lose these. Over the past few weeks, we have been rolling out email and in-product reminders that remind you to also download backup codes (sometimes called recovery keys) that can get you back into your account in the event you lose your 2FA credentials. Download your backup codes now by logging into Cloudflare, then navigating to Profile > Security & Authentication > Backup codes.

Cloudflare is critical infrastructure, and you should protect it as such. Please review the following best practices and make sure you are doing your part to secure your account.

• Use a unique password for every website, including Cloudflare, and store it in a password manager like 1Password or Keeper. These services are cross-platform and simplify the process of managing secure passwords.
• Use 2FA to make it harder for an attacker to get into your account in the event your password is leaked
• Store your backup codes securely. A password manager is the best place since it keeps the backup codes encrypted, but you can also print them and put them somewhere safe in your home.
• If you use an app to manage your 2FA keys, enable cloud backup, so that you don't lose your keys in the event you lose your phone.
• If you use a custom email domain to sign in, configure SSO ↗.
• If you use a public email domain like Gmail or Hotmail, you can also use social login with Apple, GitHub, or Google to sign in.
• If you manage a Cloudflare account for work:
  • Have at least two administrators in case one of them unexpectedly leaves your company
  • Use SCIM to automate permissions management for members in your Cloudflare account

Fine-grained permissions for Access Applications, Identity Providers (IdPs), and Targets is now available in Public Beta. This expands our RBAC model beyond account & zone-scoped roles, enabling administrators to grant permissions scoped to individual resources.

• Access Applications ↗: Grant admin permissions to specific Access Applications.
• Identity Providers ↗: Grant admin permissions to individual Identity Providers.
• Targets ↗: Grant admin rights to specific Targets

For more info:

• Get started with Cloudflare Permissioning
• Manage Member Permissioning via the UI & API

Users can now specify that they want to retrieve Cloudflare documentation as markdown rather than the previous HTML default. This can significantly reduce token consumption when used alongside Large Language Model (LLM) tools.

curl https://developers.cloudflare.com/workers/ -H 'Accept: text/markdown'  -v

If you maintain your own site and want to adopt this practice using Cloudflare Workers for your own users you can follow the example here ↗.

Cloudflare has launched sign in with GitHub as a log in option. This feature is available to all users with a verified email address who are not using SSO. To use it, simply click on the Sign in with GitHub button on the dashboard login page. You will be logged in with your primary GitHub email address.

• Log in to Cloudflare

Single sign-on (SSO) streamlines the process of logging into Cloudflare for Enterprise customers who manage a custom email domain and manage their own identity provider. Instead of managing a password and two-factor authentication credentials directly for Cloudflare, SSO lets you reuse your existing login infrastructure to seamlessly log in. SSO also provides additional security opportunities such as device health checks which are not available natively within Cloudflare.

Historically, SSO was only available for Enterprise accounts. Today, we are announcing that we are making SSO available to all users for free. We have also added the ability to directly manage SSO configurations using the API. This removes the previous requirement to contact support to configure SSO.

• Every Cloudflare feature, available to all ↗
• Configure Dashboard SSO

Two-factor authentication is the best way to help protect your account from account takeovers, but if you lose your second factor, you could be locked out of your account. Lock outs are one of the top reasons customers contact Cloudflare support, and our policies often don't allow us to bypass two-factor authentication for customers that are locked out. Today we are releasing an improvement where Cloudflare will periodically remind you to securely save your backup codes so you don't get locked out in the future.

• Two-factor authentication

Cloudflare's API now supports rate limiting headers using the pattern developed by the IETF draft on rate limiting ↗. This allows API consumers to know how many more calls are left until the rate limit is reached, as well as how long you will need to wait until more capacity is available.

Our SDKs automatically work with these new headers, backing off when rate limits are approached. There is no action required for users of the latest Cloudflare SDKs to take advantage of this.

As always, if you need any help with rate limits, please contact Support.

Headers that are always returned:

• Ratelimit: List of service limit items, composed of the limit name, the remaining quota (r) and the time next window resets (t). For example: "default";r=50;t=30
• Ratelimit-Policy: List of quota policy items, composed of the policy name, the total quota (q) and the time window the quota applies to (w). For example: "burst";q=100;w=60

Returned only when a rate limit has been reached (error code: 429):

• Retry-After: Number of Seconds until more capacity is available, rounded up

• All of Cloudflare's latest SDKs will automatically respond to the headers, instituting a backoff when limits are approached.

These new headers and back offs are only available for Cloudflare REST APIs, and will not affect GraphQL.

• Rate limits at Cloudflare ↗

Earlier this year, we announced the launch of the new Terraform v5 Provider. We are aware of the high number of issues ↗ reported by the Cloudflare community related to the v5 release. We have committed to releasing improvements on a 2 week cadence to ensure its stability and reliability, including the v5.9 release. We have also pivoted from an issue-to-issue approach to a resource-per-resource approach - we will be focusing on specific resources for every release, stabilizing the release, and closing all associated bugs with that resource before moving onto resolving migration issues.

Thank you for continuing to raise issues. We triage them weekly and they help make our products stronger.

This release includes a new resource, cloudflare_snippet, which replaces cloudflare_snippets. cloudflare_snippet is now considered deprecated but can still be used. Please utilize cloudflare_snippet as soon as possible.

• Resources stabilized:
  • cloudflare_zone_setting
  • cloudflare_worker_script
  • cloudflare_worker_route
  • tiered_cache
• NEW resource cloudflare_snippet which should be used in place of cloudflare_snippets. cloudflare_snippets is now deprecated. This enables the management of Cloudflare's snippet functionality through Terraform.
• DNS Record Improvements: Enhanced handling of DNS record drift detection
• Load Balancer Fixes: Resolved created_on field inconsistencies and improved pool configuration handling
• Bot Management: Enhanced auto-update model state consistency and fight mode configurations
• Other bug fixes

For a more detailed look at all of the changes, refer to the changelog ↗ in GitHub.

• #5921: In cloudflare_ruleset removing an existing rule causes recreation of later rules ↗
• #5904: cloudflare_zero_trust_access_application is not idempotent ↗
• #5898: (cloudflare_workers_script) Durable Object migrations not applied ↗
• #5892: cloudflare_workers_script secret_text environment variable gets replaced on every deploy ↗
• #5891: cloudflare_zone suddenly started showing drift ↗
• #5882: cloudflare_zero_trust_list always marked for change due to read only attributes ↗
• #5879: cloudflare_zero_trust_gateway_certificate unable to manage resource (cant mark as active/inactive) ↗
• #5858: cloudflare_dns_records is always updated in-place ↗
• #5839: Recurring change on cloudflare_zero_trust_gateway_policy after upgrade to V5 provider & also setting expiration fails ↗
• #5811: Reusable policies are imported as inline type for cloudflare_zero_trust_access_application ↗
• #5795: cloudflare_zone_setting inconsistent value of "editable" upon apply ↗
• #5789: Pagination issue fetching all policies in "cloudflare_zero_trust_access_policies" data source ↗
• #5770: cloudflare_zero_trust_access_application type warp diff on every apply ↗
• #5765: V5 / cloudflare_zone_dnssec fails with HTTP/400 "Malformed request body" ↗
• #5755: Unable to manage Cloudflare managed WAF rules via Terraform ↗
• #5738: v4 to v5 upgrade failing Error: no schema available AND Unable to Read Previously Saved State for UpgradeResourceState ↗
• #5727: cloudflare_ruleset http_request_cache_settings bypass mismatch between dashboard and terraform ↗
• #5700: cloudflare_account_member invalid type 'string' for field 'roles' ↗

If you have an unaddressed issue with the provider, we encourage you to check the open issues ↗ and open a new issue if one does not already exist for what you are experiencing.

We suggest holding off on migration to v5 while we work on stabilization. This help will you avoid any blocking issues while the Terraform resources are actively being stabilized.

If you'd like more information on migrating from v4 to v5, please make use of the migration guide ↗. We have provided automated migration scripts using Grit which simplify the transition. These do not support implementations which use Terraform modules, so customers making use of modules need to migrate manually. Please make use of terraform plan to test your changes before applying, and let us know if you encounter any additional issues by reporting to our GitHub repository ↗.

• Terraform provider ↗
• Documentation on using Terraform with Cloudflare
• GitHub Repository ↗