apiPulse.app

Cloudflare

Cloudflare developer platform and API changelog updates

Cloudflare API Changelog Monitoring

Cloudflare changes can impact edge behavior, DNS workflows, security automation, and API-driven infrastructure management. This Cloudflare API Changelog Monitoring page gives teams one place to review new platform updates and assess operational risk quickly.

Effective Cloudflare API Changelog Monitoring gives infrastructure teams earlier visibility into changes that might influence deployment flows, zone automation, or security controls. The result is a tighter response loop when something needs testing, rollout planning, or internal communication.

The benefit of Cloudflare API Changelog Monitoring is simple: your team gets a repeatable way to watch changes, evaluate risk, and act before small upstream updates turn into customer-facing bugs. Cloudflare developer platform and API changelog updates

Cloudflare API down?

Cloudflare API down? Soon we will add direct API status monitoring alongside Cloudflare API Changelog Monitoring. For now, go to the official API status page on the Cloudflare website. In the future, we plan to detect potential outages even before the public status page is updated.

Recent changes

Showing the last 10 changes from this feed.

07-16-2026

Access, Cloudflare One - Bulk print PDFs for browser-based RDP

Users in browser-based RDP sessions can now print multiple PDF files as a single print job. Copy the files to your clipboard on the remote machine, then select Print all PDFs in the clipboard panel. The files are combined into one PDF and sent to your local printer. Bulk print is available in Chromium-based browsers and Firefox. For more information, refer to Print PDFs for browser-based RDP.

07-16-2026

Flagship - Manage Flagship from the command line with Wrangler

Wrangler now includes wrangler flagship, a command suite for managing Flagship apps and feature flags from your terminal. Create an app and, if you use it from a Worker, add it to your wrangler.json or wrangler.jsonc file as a binding: wrangler flagship apps create "My Worker App" \ --binding FLAGS \ --update-config Then create flags for the behavior you want to control. Flags can be booleans, strings, numbers, or JSON values: wrangler flagship flags create new-checkout wrangler flagship flags create checkout-flow \ --variation control=old-checkout \ --variation treatment=new-checkout \ --default control \ --type string After a flag exists, change its default variation or use enable and disable commands as kill switches. Existing targeting rules continue to apply unless you change or clear them explicitly: wrangler flagship flags update checkout-flow --default treatmentwrangler flagship flags disable checkout-flowwrangler flagship flags enable checkout-flow For release workflows, use rollout, split, and rules to change exposure without redeploying your Worker: wrangler flagship flags rollout new-checkout \ --to on \ --percentage 25 \ --by user_id wrangler flagship flags split checkout-flow \ --weight control=80 \ --weight treatment=20 \ --by user_id wrangler flagship flags rules update checkout-flow \ --priority 1 \ --when "country equals US" These commands can also be used from CI/CD pipelines, scripts, and AI agents to inspect Flagship state, update flag behavior, or roll back changes through Wrangler. Refer to the wrangler flagship command reference for the full command guide.

07-15-2026

Email Service, Queues - Subscribe to Email Sending events with Queues

You can now subscribe to Email Sending events through Queues event subscriptions and receive outbound transactional email lifecycle events on a queue. Each subscription is scoped to one sending domain — either the zone apex, such as example.com, or a verified sending subdomain, such as send.example.com. Six event types are published: message.delivered, message.deferred, message.bounced, message.failed, message.rejected, and message.complained. Use them to track deliverability, react to bounces and complaints, and drive suppression or retry logic. Email Routing events are not published on this source. Each event includes the message details, delivery status, and SMTP response: { "type": "cf.email.sending.message.delivered", "source": { "type": "email.sending", "zoneId": "023e105f4ecef8ad9ca31a8372d0c353", "domain": "example.com" }, "payload": { "messageId": "0101018f7d0c4d9a-msg-deadbeef", "recipient": "user@example.net", "terminal": true, "delivery": { "status": "delivered", "smtpStatusCode": "250" } }} Refer to Event subscriptions to see all event types and example payloads.

07-15-2026

Gateway, DNS - Internal DNS is now generally available

Internal DNS is now generally available. Internal DNS provides authoritative and recursive DNS for private networks on the same global network and control plane you already use for public DNS, Zero Trust, and application services. Why it matters Consolidate DNS operations. Public and private DNS run on one platform, with one API, one audit trail, and one place to set policy. Simplify split-horizon DNS. Internal and external resolution are defined as separate views over shared zones, managed from a single control plane — so there is no drift to chase down. Extend Zero Trust to DNS. Resolver policies decide which users and devices resolve against which view, enforced by the same Gateway that already governs the rest of your traffic. Setting up Internal DNS takes three steps: create a zone, create a view, and define a resolver policy. POST /zones{ "account": { "id": "" }, "name": "corp.internal", "type": "internal"} Internal DNS is included with Cloudflare Gateway for Enterprise customers. To get started, refer to the Internal DNS documentation.

07-15-2026

KV - Deprecate legacy Workers KV namespace API routes

The legacy Workers KV API routes under /accounts/{account_id}/workers/namespaces/* are deprecated as of July 15, 2026, and will stop working on October 15, 2026. Migrate to the documented Workers KV API routes under /accounts/{account_id}/storage/kv/namespaces/* before that date. The legacy and replacement routes are interchangeable. They accept the same request parameters and return the same response payloads. To migrate, update the URL path from /workers/namespaces/ to /storage/kv/namespaces/. What you need to do Update any integration that calls a route under /accounts/{account_id}/workers/namespaces/ to use the equivalent route under /accounts/{account_id}/storage/kv/namespaces/. The migration is a direct URL path substitution — request parameters and response payloads are identical: GET and POST /accounts/{account_id}/workers/namespaces → GET and POST /accounts/{account_id}/storage/kv/namespaces GET, PUT, and DELETE /accounts/{account_id}/workers/namespaces/{namespace_id} → GET, PUT, and DELETE /accounts/{account_id}/storage/kv/namespaces/{namespace_id} GET /accounts/{account_id}/workers/namespaces/{namespace_id}/keys → GET /accounts/{account_id}/storage/kv/namespaces/{namespace_id}/keys GET /accounts/{account_id}/workers/namespaces/{namespace_id}/metadata/{key_name} → GET /accounts/{account_id}/storage/kv/namespaces/{namespace_id}/metadata/{key_name} GET, PUT, and DELETE /accounts/{account_id}/workers/namespaces/{namespace_id}/values/{key_name} → GET, PUT, and DELETE /accounts/{account_id}/storage/kv/namespaces/{namespace_id}/values/{key_name} For more information about the deprecation timeline, refer to API deprecations.

07-14-2026

Cloudflare Web Analytics - Improved reliability for account-wide Web Analytics dashboards

Cloudflare Web Analytics (Real User Monitoring) has rolled out performance optimizations to significantly improve the stability and loading speed of account-wide dashboards. For larger accounts (with >100 Web Analytics sites), loading the aggregate account-wide view would often fail, running into timeouts or unexpected interface errors due to the massive scale of parallel query processing. This update optimizes how high-volume multi-site data is queried to reduce errors and provide a snappier dashboard experience. Accounts with up to 1,000 sites will now be able to load this account-wide aggregate view without experiencing misleading errors. If you have an account with over 1,000 sites, we cannot currently aggregate over this volume due to processing constraints but you will now be presented with a clear error and instruction to filter to the relevant site(s) you wish to see the data for.

07-14-2026

WAF - WAF Release - 2026-07-14

This release introduces new rules targeting critical infrastructure vulnerabilities. These include an unauthenticated memory disclosure flaw in Citrix NetScaler ADC and Gateway (CVE-2026-8451) and a high-severity pre-authentication remote code execution (RCE) vulnerability in Progress Kemp LoadMaster (CVE-2026-8037). Key Findings CVE-2026-8451: An insufficient input validation vulnerability affects Citrix NetScaler ADC and NetScaler Gateway appliances configured as a SAML Identity Provider (IdP). Remote, unauthenticated attackers can exploit this flaw by sending malformed requests to trigger a memory overread, allowing them to leak chunks of sensitive data from adjacent appliance memory. CVE-2026-8037: A critical OS command injection vulnerability in Progress Kemp LoadMaster load balancers allows unauthenticated remote attackers to achieve remote code execution (RCE). RulesetRule IDLegacy Rule IDDescriptionPrevious ActionNew ActionCommentsCloudflare Managed Ruleset78826e3223b94da493a2ade876973ac4 N/ACitrix Netscaler ADC - Insufficient Input Validation - CVE:CVE-2026-8451LogBlockThis is a new detection.Cloudflare Managed Ruleset6b64d216620449fbb273d07910233f36 N/AProgress Kemp LoadMaster - Remote Code Execution - CVE:CVE-2026-8037LogBlockThis is a new detection.

07-14-2026

WAF - WAF Release - Scheduled changes for 2026-07-20

Announcement DateRelease DateRelease BehaviorLegacy Rule IDRule IDDescriptionComments2026-07-122026-07-20LogN/A7fbdc9407bdb4a4eae2b3d91215e7d31 SSRF - Restricted ProtocolThis is a new detection.2026-07-122026-07-20LogN/A6ca512d240d848d6a0c7ef42a935ee5d SSRF - Obfuscated HostThis is a new detection.2026-07-122026-07-20LogN/Aa3fb0870c38440d8a9a0eba81b0230ac LFI - Path TraversalThis is a new detection.2026-07-142026-07-20LogN/A452a04be3f73458c863d8dae61349c8b Adobe ColdFusion - File Upload Path Traversal - CVE:CVE-2026-48276This is a new detection.2026-07-142026-07-20LogN/Aa53a3fb491c64d74908081ee9cb61eac Adobe ColdFusion - Path Traversal - CVE:CVE-2026-48282This is a new detection.2026-07-142026-07-20LogN/Ad8b63828c2344d919b94d2594ac5e21f XSS — JS Bracket Concat Obfuscation - BodyThis is a new detection.2026-07-142026-07-20LogN/A264a83a764be428ca41d516ff31f5559 XSS — JS Bracket Concat Obfuscation - HeadersThis is a new detection.2026-07-142026-07-20LogN/A4ba21a60837244029183b782987984fd XSS — JS Bracket Concat Obfuscation - URIThis is a new detection.

07-14-2026

Workers - Platforms can now create Temporary Accounts via the Cloudflare API

Platforms can now create temporary preview accounts through the Cloudflare REST API. This lets your platform deploy a live Worker before the user signs in to Cloudflare. With the Temporary Accounts API, coding agents, AI app builders, and other platforms can build a similar flow for generated Workers and supported resources. Your platform can keep users in its onboarding flow while they generate, deploy, and test an application. Users do not need an existing Cloudflare account, and your platform does not need write access to one. The API returns a claim URL that lets the user make the temporary account and its resources permanent. Cloudflare Drop demonstrates this preview-and-claim pattern for static sites. Someone can upload a site, test and share it for one hour, then sign in or create an account only when they want to keep it. This API expands the flow first introduced with wrangler deploy --temporary. Your backend now controls the provisioning and deployment experience directly: Show Cloudflare's Terms of Service and Privacy Policy in your product, and require the user to accept them. Request and solve a proof-of-work challenge. Create a temporary preview account. Deploy with the returned temporary account ID and API token. Show the deployed Worker URL and claim URL to the user. curl "https://api.cloudflare.com/client/v4/provisioning/previews/challenge" \ -X POST \ -H "Content-Type: application/json" \ --data '{}' curl "https://api.cloudflare.com/client/v4/provisioning/previews" \ -X POST \ -H "Content-Type: application/json" \ --data '{ "termsOfService": "https://www.cloudflare.com/terms/", "privacyPolicy": "https://www.cloudflare.com/privacypolicy/", "acceptTermsOfService": "yes", "challengeToken": "", "solution": { "checkpoints": "" } }' For the complete API flow, proof-of-work requirements, supported products, and limits, refer to Claim deployments (temporary accounts). For the background and design goals behind this flow, refer to Temporary Cloudflare Accounts for AI agents.

07-13-2026

Agents, Workers - Agents can respond to MCP elicitation requests

Agents connected to Model Context Protocol (MCP) servers with addMcpServer can now handle elicitation requests. Elicitation lets an MCP server request user input while it handles a tool call. Form mode collects structured, non-sensitive data. URL mode asks for consent before opening an out-of-band flow, such as third-party authorization or payment. sequenceDiagram participant User participant Agent as Agent (MCP client) participant Server as MCP server participant Browser Server->>Agent: elicitation/create Agent->>User: Show server, reason, and input or URL User->>Agent: Submit, open, decline, or cancel Agent->>Browser: Open URL after consent (URL mode) Agent->>Server: accept, decline, or cancel Server-->>Agent: Optional URL completion notification Register a handler for each mode your Agent supports in onStart(): JavaScript import { Agent } from "agents"; export class MyAgent extends Agent { onStart() { this.mcp.configureElicitationHandlers({ form: (request, serverId) => this.forwardToUser(request, serverId), url: (request, serverId) => this.forwardToUser(request, serverId), }); } forwardToUser(request, serverId) { // Show the request in your UI and resolve after the user responds. throw new Error( `Implement elicitation for ${serverId}: ${request.params.message}`, ); }} TypeScript import { Agent } from "agents";import type { ElicitRequest, ElicitResult } from "agents/mcp"; export class MyAgent extends Agent { onStart() { this.mcp.configureElicitationHandlers({ form: (request, serverId) => this.forwardToUser(request, serverId), url: (request, serverId) => this.forwardToUser(request, serverId), }); } private forwardToUser( request: ElicitRequest, serverId: string, ): Promise { // Show the request in your UI and resolve after the user responds. throw new Error( `Implement elicitation for ${serverId}: ${request.params.message}`, ); }} Connections advertise only the modes with configured handlers. An Agent without handlers advertises no elicitation capability, which lets the server use its fallback. The SDK stores the advertised modes with each MCP server registration so they survive Durable Object hibernation. Callback functions remain in memory and reattach when onStart() runs. For implementation details and a browser forwarding pattern, refer to MCP client elicitation. The mcp-client and mcp-elicitation examples implement both sides. Upgrade To update to this release: npm i agents@latest yarn add agents@latest pnpm add agents@latest bun add agents@latest