Download the PHP package konsulting/justgiving-api-sdk without Composer

JustGiving API SDK

A PHP SDK for communicating with the JustGiving API. Based on the original SDK by JustGiving and contributors.

Installation

Install via composer:

Quick start

See the JustGiving API documentation for more information.

Usage

Setup

The client requires an authentication object with your JustGiving API credentials. The available classes are:

• AppAuth($appId, $secretKey = null) for unprotected endpoints
  • Note: If JustGiving has generated a secret key for your app ID, you must include it here (even though the endpoints do not require authorisation). If not, just provide the app ID.
• BasicAuth($appId, $username, $password) for protected endpoints, where you have the username and password.
• BearerAuth($appId, $secretKey, $token) for protected endpoints, where you have a bearer token (from oAuth).

You may also pass in a PSR-18 HTTP client as the second parameter. If this is not provided (or set to null), a default Guzzle client will be used.

The API base URL and version are set automatically, but may be overridden by passing an associative array with keys root_domain and api_version as the third argument.

For example:

Querying the API

The SDK defines a separate client class for each resource as define by the API documentation, and each of those classes contain methods that correspond to API actions. To get a resource class, call the name of the resource as a property on the $client we built up earlier, for example $client->account or $client->charity. The relevant method is then called on top of that.

Method aliases

The actual methods on the class are named in camelCase and are often shortened from the original API action for brevity. However, there are aliases defined for every resource class so that the API action names may be used to interact with the SDK.

For example, both of these examples will work to get the status of a donation:

Models

Some API actions (e.g. creating or updating resources) require a set of data grouped together in an object. To achieve this, a model class has been defined for each separate occasion when this is necessary, for example Team or JoinTeamRequest. These model classes all extend the parent Model class, which adds some useful functionality.

Data can be added to a model in several ways: it can be passed to the constructor as an array, passed to the fill() method as an array, or each property can be set individually. The fill() method may be used multiple times to set different properties, and will only override existing properties if they are explicitly passed in as an array item.

Custom API requests

The client allows custom requests via the request() method. This takes the HTTP method, the endpoint URI and any request options (e.g. headers). You may also override client options, for example the API version. These overrides will only apply for a single request.

For example, to perform a request to the beta campaign endpoint:

If the endpoint requires a payload, JSON may be passed in as an HTTP option. A more complete example:

Working with responses

The SDK returns an instance of JustGivingApiSdk\Support\Response from each request. This implements the PSR-7 ResponseInterface and so allows access to the full HTTP response received by the client.

Response body

The raw response body can be accessed via

However, the API returns JSON and so this method can prove to be an inefficient way of working with data. If body is accessed as a property on the response, the decoded JSON body is returned.

From here, the response data is represented by arrays or objects of type StdClass which contain the data we want to use.

The response class also allows body properties to be called directly on itself, i.e. the following is also valid:

Errors

The API provides two formats of error message(s): the first is a general error message relating to the whole request (e.g. That email address is already in use), and the second is a list of error messages that relate to problems with specific parts of the request or data, with an identifier and description (e.g. ID: FirstNameNotSpecified, description The FirstName field is required.).

In the API documentation, the former is referred to as being the errorMessage property, and the latter refers to errors contained in Error objects (with properties Error.id and Error.desc).

Errors can be accessed via the errors property of the response object, which presents any errors present in a unified array format of $identifier => $description. If there is a general error, it is given the identifier General and added to the array like any other error. The reason phrase given with the response (accessible via the getReasonPhrase() method) is added to the errors array and given the identifier ReasonPhrase.

For example:

Now, say we correctly created that account and went to create a new account with the same email:

Response helper methods

There are a couple of helper methods on the response to make some API calls and validation easier:

• $response->wasSuccessful() – returns true if the response has a status code of 2xx.
• $response->hasErrorMessages() – returns true if the response has any error messages. Note: Some API actions do not return any error messages upon failure. This flag should be used to determine whether there is any useful error information to display, not to check if the action succeeded (use wasSuccessful() instead).
• $response->existenceCheck() – returns true if the response had a status code of 200, false if the status code is 404, and throws an exception otherwise. Useful for API calls that check for the existence of a resource.