The Parse PHP SDK covers the whole server API, with some stale corners

The whole server surface, not a slice of it

The SDK is described as a library that gives you access to the powerful Parse Server backend from your PHP app, and the table of contents in the README shows how much of the API that covers. There are use declarations and Parse objects, then users with session handling and verification emails, then ACLs, then queries with aggregate, distinct and relative time, then cloud functions and cloud jobs, then config, analytics, files, and push with three delivery modes, to channels, with a query and with an audience, plus push status. Server info with version and features closes the API list, and then schema management with index and purge, and logs. That breadth matters for a backend SDK, because an application that has to call the REST API by hand for the parts the client does not cover ends up with two styles of code doing the same thing.

Composer install, and a version constraint worth checking

Installation has three documented routes, and Composer is the one to use. You create a `composer.json` in the root of your project:

{
    "require": {
        "parse/php-sdk" : "1.5.*"
    }
}

then run `composer install` to download the SDK and set up the autoloader, and require it from your script:

require 'vendor/autoload.php';

If you would rather work from the source, the README also gives a git route with `git clone https://github.com/parse-community/parse-php-sdk.git` and a require of the `autoload.php` file, which the repository ships at its root alongside `composer.json`, `src/` and `tests/`. One thing to notice in the Composer example is that the constraint is `1.5.*` while the current release line is 2.x, so the snippet in the README is out of step with the package it describes. The badge in the same README is more current, naming PHP 8.1, 8.2 and 8.3.

Initialising the client and pointing it at your server

Two calls set the client up, and the README's ordering matters. First you initialise the ParseClient with your Parse API keys:

ParseClient::initialize( $app_id, $rest_key, $master_key );

and if your server does not use or require a REST key, the README says you can omit it safely by passing null in its place:

ParseClient::initialize( $app_id, null, $master_key );

Second, directly after initialising, you set the server URL, which is the host and the route prefix of your Parse Server:

ParseClient::setServerURL('https://my-parse-server.com:port','parse');

The README notes that the default port for Parse Server is `1337` and that the second parameter is the route prefix, so a server at `http://example.com:1337/parse` is set with `ParseClient::setServerURL('https://example.com:1337','parse');`. The master key is the one to think about. It bypasses the permission layer, so it belongs on a server and never in a client that ships to browsers.

The health check that tells you your URL is right

Before you trust your configuration, the SDK gives you a way to check it. You can run a health check on your server:

$health = ParseClient::getServerHealth();
if($health['status'] === 200) {
    // everything looks good!
}

The response has a shape the README spells out, with the HTTP response code in `status` and the server's own reply under `response`:

{
    "status"    : 200,
    "response"  : {
        "status" : "ok"
    }
}

The `status` value is the HTTP response code and `response` contains what the server replies with, and any further details are also under `response`, which the README says you can use to check and determine the availability of parse-server before making requests. There is a caveat the README is careful about. It is not guaranteed that `response` will be a parsable JSON array, and if the response cannot be decoded it is returned as a string instead, so a health check that assumes an array will break on a server that answers with something else.

Users, sessions and the verification email path

The user section of the README is where the SDK's session handling shows through, and it is worth reading rather than skimming. The table of contents lists users, then a sub-section on session id and session fixation, and a sub-section on verification emails. Session fixation is the reason that sub-section exists. A token handed out before login and reused after it is the classic session fixation problem, and a client library that manages session tokens has to get the behaviour right whether you log in, whether a session is refreshed, and whether the user is signing up and confirming. Verification email is the other half, and the SDK is where the request for that email is made and where the confirmation code comes back. The SDK is a thin client by design, so these behaviours live in the server, and the client's job is to pass the right things and surface the results.

Queries, aggregates and the relative time helper

The query layer is the part of the API a PHP application touches most, and the table of contents shows three capabilities that are worth calling out because they are the ones hand written REST calls get wrong. Aggregate is the server side aggregation over a query, which is not the same as aggregating the results you pulled into PHP, and the difference matters once the data set is larger than one page. Distinct is the server side list of distinct values for a key, and relative time is a date query helper for the server's date semantics. Paired with them, the ACL support covers the permission model, which for a Parse Server application is a security surface rather than a convenience, since the client is where read and write permissions are expressed.

The toolchain, the licences and the release line

The repository is a conventional PHP package with a Node based toolchain for its own development. The `package.json` scripts run PHPUnit for the unit tests and a separate stream bootstrap variant, run PHPUnit with Xdebug for clover coverage, run PHP_CodeSniffer with a shared standard from `phpcs.xml.dist`, generate API documentation with phpdoc into a titled Parse PHP SDK API Reference, and start a local Parse Server for the integration tests through `mongodb-runner` with a pinned MongoDB version and a replicaset topology. Releases are handled by semantic-release, and the dev dependencies pull `parse-server` from the alpha branch of the upstream repository, which tells you the SDK is tested against a moving server. Two licence details need care. The package manifest declares BSD-3-Clause, while the platform classifies the repository licence as a custom one it cannot classify, so the `LICENSE` file is the authority. And the release line is old, with 2.4.0 published on 2024-06-27 after 2.3.2 and 2.3.1 in May 2023, while the last push to the repository was on 2026-04-04.

Editorial conclusion

Adopt parse-php-sdk when your backend is PHP and your data lives in a Parse Server, since it exposes the full server surface, from queries and cloud functions to push and schema, and it is the only PHP client for the platform. Do not adopt it on the strength of the README's own installation notes, because the prose still says the SDK requires PHP 5.4 or newer and runs on HHVM, which is several major versions out of date, while the badge and the compatibility table point at PHP 8.1 to 8.3. Verify first which PHP versions your project must support and confirm the master key handling, since the client is initialised with application, REST and master keys, and check the release line, as the newest tagged version is 2.4.0 from 2024-06-27.

Frequently asked questions

Official sources

1. Issues
2. parse-community/parse-php-sdk on GitHub
3. Project website
4. README
5. Releases