---
title: Cloudflare Deprecates the Zone Settings Batch API
description: Cloudflare retires batched zone settings reads/writes on 2027-03-31. Automation using the single-request endpoint needs to switch to per-setting calls.
date: 2026-08-06T00:00:00.000Z
category: data-automation
tags: cloudflare, api, deprecation, zone-settings
---

## Quick Answer

Cloudflare deprecates the Zone Settings Batch API, `GET`/`PATCH /zones/{zone_id}/settings`, which reads or edits multiple zone settings in a single request. It reaches end of life on 2027-03-31 (Cloudflare extended this from an original 2026-09-15 date). Automation using that batch endpoint needs to migrate to per-setting endpoints (`/zones/{zone_id}/settings/{setting_name}`) before then, one call per setting instead of one call for all of them.

## What's actually changing

[Cloudflare's own changelog](https://developers.cloudflare.com/fundamentals/api/reference/deprecations/) states the change plainly:

> "The Zone Settings Batch API endpoints, which read and edit multiple zone settings in a single request, are deprecated"

Unlike most of the other deprecations in this wave, this isn't a URL path swap with the same request/response shape. The batch endpoint's whole value was reading or writing several settings (SSL mode, always-use-HTTPS, minify, and so on) in one call. The [per-setting endpoints](https://developers.cloudflare.com/api/resources/zones/subresources/settings/methods/edit/) Cloudflare points to instead follow the pattern `/zones/{zone_id}/settings/{setting_name}`, confirmed elsewhere in Cloudflare's own API deprecations data for individual settings like `cname_flattening`. Migrating means genuinely restructuring any code that built one batched request into a loop, or a series, of per-setting requests.

## Structural Comparison Matrix

| Operational Aspect                   | Batch API (deprecated)      | Per-setting API                            |
| :----------------------------------- | :-------------------------- | :----------------------------------------- |
| **Requests to configure N settings** | 1                           | N                                          |
| **Endpoint shape**                   | `/zones/{zone_id}/settings` | `/zones/{zone_id}/settings/{setting_name}` |
| **Available after 2027-03-31**       | Removed                     | Active                                     |

## Fix it: loop over per-setting calls

```bash title="before: one batched request"
curl -X PATCH \
  "https://api.cloudflare.com/client/v4/zones/<zone_id>/settings" \
  -H "Authorization: Bearer <api_token>" \
  -H "Content-Type: application/json" \
  --data '{"items":[{"id":"ssl","value":"full"},{"id":"always_use_https","value":"on"}]}'
```

```bash title="after: one request per setting"
curl -X PATCH \
  "https://api.cloudflare.com/client/v4/zones/<zone_id>/settings/ssl" \
  -H "Authorization: Bearer <api_token>" \
  -H "Content-Type: application/json" \
  --data '{"value":"full"}'

curl -X PATCH \
  "https://api.cloudflare.com/client/v4/zones/<zone_id>/settings/always_use_https" \
  -H "Authorization: Bearer <api_token>" \
  -H "Content-Type: application/json" \
  --data '{"value":"on"}'
```

<Callout type="warning" title="This changes request volume, not just syntax">
  A pipeline configuring many zones with many settings each goes from one
  request per zone to one request per setting per zone. If the automation runs
  against API rate limits or is billed per request anywhere in its stack, this
  is a real capacity-planning change, not a drop-in fix.
</Callout>

## Confirmed version

Sourced from [Cloudflare's own API deprecations reference](https://developers.cloudflare.com/fundamentals/api/reference/deprecations/), re-checked 2026-08-13. That page now states the end-of-life date "has been extended to March 31, 2027 (previously September 15, 2026)": this post originally used the earlier date, corrected here to match Cloudflare's current published timeline. Migrate before the current 2027-03-31 date rather than the original one. Browse more posts like this in the [Data Automation](/data-automation) archive.
