cloudflare-php: a hand written PHP SDK for part of the Cloudflare v4 API

A community binding that deliberately covers only part of the API

The most important thing in this README is a note, and it appears before anything else. The project states that it is a community maintained PHP SDK covering a subset of the Cloudflare API, that a comprehensive, auto generated PHP SDK is planned for the future, and that in the meantime, for full API coverage, you should use the Cloudflare API directly. That framing sets expectations better than most SDKs do. The audience is a PHP developer who needs to script a specific operation against a Cloudflare account, such as editing DNS records or listing zones, and who wants typed method calls instead of assembling URLs and JSON payloads by hand. It is not a project for a team that intends to cover the whole platform, and the endpoint checklist in the README makes the boundary visible: DNS records, DNS analytics, zones, partial user administration, Cloudflare IPs, page rules, the Web Application Firewall, custom hostnames, TLS settings, zone lockdown and user agent block rules, Railgun administration, Origin CA, crypto, load balancers and firewall settings are marked as covered, while virtual DNS management, organization administration and keyless SSL are marked as not covered.

Composer, PHP 8.1, and a package name that is not the repo name

Installation is a single Composer command, and the package is published under a different name than the repository, which catches people out. The README says to install via Composer and points at the cloudflare/sdk package on Packagist, and the requirement is PHP 8.1 or later.

composer require cloudflare/sdk

The PHP 8.1 floor is a real constraint and a reasonable one for a library that was rewritten for the 2.x line, but it rules out the older shared hosting many small WordPress and PHP applications still run on. Note also that the package name and the namespace are separate things: the Composer package is cloudflare/sdk while the code lives under the Cloudflare\API namespace, and the README refers to the class namespace as Cloudflare\API\Endpoints. If you are looking for this library by searching for the repository name, you will not find the package you need to require.

Auth, adapter, endpoint: three objects before your first call

The getting started example is five lines and shows the whole structure of the library. You build an authentication object with an email and a key, wrap it in an adapter, and pass that adapter to an endpoint class. The adapter in the example is the Guzzle one, which means the library delegates the actual HTTP work to Guzzle rather than implementing it, and the adapter is the seam where you could substitute a different HTTP client. The endpoint class shown is the User one, and the call is a single method. Each API call is provided through a similarly named function within a class in the endpoints namespace, so the shape of the library mirrors the shape of the API documentation, which is what makes a partial coverage library navigable.

$key     = new Cloudflare\API\Auth\APIKey('[email protected]', 'apiKey');
$adapter = new Cloudflare\API\Adapter\Guzzle($key);
$user    = new Cloudflare\API\Endpoints\User($adapter);

echo $user->getUserID();

Two details in that snippet are worth flagging for production use. The key is passed as a literal string, which is fine in a tutorial and wrong in a real deployment, so you would read it from configuration or the environment instead. And only the API key authentication object is shown, so if your account uses a token instead, the README does not document that path.

Makefile targets for fixing, linting and testing

The repository ships a Makefile with four targets, which tells you a lot about the development setup. The default target runs lint and then test. There is a fix target that applies php-cs-fixer using the .php-cs-fixer.php configuration in the repository root, and a lint target that runs the same fixer in dry-run mode followed by phpmd over both src/ and tests/ using phpmd.xml. The test target runs phpunit with the phpunit.xml configuration. So the quality gate is style plus static analysis plus unit tests, all wired into one make invocation, and the presence of a separate .php-cs-fixer.php, phpmd.xml and phpunit.xml at the root means the rules are checked in rather than left to each contributor's setup. For a contributor, the loop is straightforward: make fix, then make, then open a pull request, with CONTRIBUTING.md linked from the README as the starting point.

Version 2.0.0 after a two year gap

The release history is short and lumpy. Version 1.3.0 was published on 2021-10-13, version 1.4.0 on 2024-12-17, and version 2.0.0 on 2026-06-18, which is also the date of the last push to the repository. The repository is not archived, but the gap between 1.3.0 and 1.4.0 is about three years, and the gap before 2.0.0 is another year and a half. That pattern says this is a project maintained when someone needs it rather than on a schedule, and it is a fair reason to read the CHANGELOG before upgrading, since a major version bump after that kind of hiatus is where breaking changes live. The licence is the 3-clause BSD license, which is permissive and lets you vendor the library into a closed source product without licensing obligations, as long as the licence text and copyright notice are kept. The project also welcomes community contribution, with CONTRIBUTING.md in the repository root.

Where this SDK stops being the right answer

There is a clear wrong-tool case here, and the README names it. If your code needs an endpoint outside the covered list, such as organization administration or keyless SSL, this library cannot serve you, and the alternative the README offers is not another SDK but calling the Cloudflare API directly, which means writing and maintaining your own request layer, error handling and pagination. The second case is coverage drift. Because the binding is hand written against a subset of a v4 API that Cloudflare extends continuously, an endpoint can change shape underneath you, and the library cannot be auto regenerated, so fixes land only when a maintainer notices. The third case is planning: the note about a comprehensive auto-generated SDK being planned for the future means the current answer is a stopgap, and if you are starting a multi-year integration you may be waiting on that rewrite. A third alternative exists in the PHP ecosystem generally, which is a generated client from an OpenAPI description, but the README makes no claim about such a tool, so you would be evaluating that on its own.

Editorial conclusion

Adopt cloudflare-php if you need a small, readable PHP client for a handful of Cloudflare endpoints, such as DNS records, zones, page rules or load balancers, and you would rather not hand write HTTP calls. Skip it if you need full API coverage, because the README states the library covers a subset and points to the Cloudflare API directly for the rest. Verify first which endpoints your workflow touches against the checked list, and check the 2.0.0 release date before you adopt, because the previous tagged version was 1.4.0 in 2024.

Frequently asked questions

Official sources

1. cloudflare/cloudflare-php on GitHub
2. Issues
3. License: BSD-3-Clause
4. README
5. Releases