Cloudcheck API Documentation

Overview

The Cloudcheck API service enables a reporting entity to integrate the Cloudcheck service into its website. This allows the reporting entity to perform electronic verification (EV) on a customer.

Terminology

  • reporting entity – you, as the organisation required to perform EV on your customer
  • customer – the end user whose details you are required to verify

Server

The API service has a base URL of https://api.cloudcheck.co.nz/ for New Zealand customers, or https://api.cloudcheck.com.au/ for Australian customers.

Request Signing

All requests made to Cloudcheck API endpoints must be signed.

The signature is constructed by taking the request path, appending all request parameters in alphabetical order with a semi-colon after each parameter, and generating an HMAC SHA-256 hash of the result, using the supplied API Secret Key as the HMAC key. This signature must be generated separately for each request made to the API.

To generate the string to use for the signature, sort the parameters alphabetically, and concatenate the request data as follows:

  1. The path of the request (e.g. /verify/ or /verify/pdf)
  2. The first request parameter in the format parameter=value (do not URL encode the value when generating the signature)
  3. A semi-colon
  4. Repeat steps 2–3 for each remaining parameter

Once this string has been generated, create the HMAC SHA-256 hash from this string and the API Secret Key provided to you.

Finally, convert the bytes returned by the HMAC method to a hexadecimal string, and pass this string to the API as the signature parameter. Note this is not Base64 encoded.

Example

Code Samples

Postman Collection

We provide a Postman collection to get you started on your integration with our APIs. Keep in mind the following regarding this collection:

  • The examples are provided for illustration purposes only and are not intended to be used in your final implementation. For example, the method used to create a nonce is not industrial-strength and will not reliably produce a unique result.
  • The API calls made by this collection use test data sources, therefore you may not get the results that you expect if using real data. In some cases (e.g. Cloudcheck Tree) we don’t have any applicable test data sources, therefore you will get a permissions error.
  • The Postman Collection contains a test API key and secret, which will not return any results. If you have been supplied your own API key and secret, please add them to Postman by editing collection, click on the "Variables" tab, and enter your values in the "Current Value" column.

Download the Postman collection.

For instructions on how to install and use this Postman collection, refer to this video.

OpenAPI Documentation

We provide OpenAPI (or Swagger) documentation for our APIs, which can be found here.

Error Codes

Code Reason
101 Access key is missing or incorrect.
102 One of the required fields listed above is missing or empty.
103 The timestamp is older than the maximum allowed. Ensure your timestamp is generated in milliseconds since the Epoch. Note Unix time (which you can see at this site) is in seconds, so you will need to add "000" to the end.
104 The supplied nonce parameter has been previously used.
105 The supplied verification token is not associated with a verification request for this access key.
106 The signature calculated does not match the signature supplied.
107 A parameter was supplied in an invalid format.
108 You do not have permission to access this resource.
110 The query did not return any results.
111 The query failed for an unspecified reason.
112 The query could not be performed for an unspecified reason.
113 The operation could not be performed for an unspecified reason.

An error response can be at the top level or at the second level, as shown in these examples:

Example

The fields in an error response include:

  • error An error code from the table above.
  • message A description of the error.
  • fields A comma-separated list of fields in error (optional).
  • errorDetail A comma-separated list of detailed messages (optional).

Webhooks

When certain events occur we can send a notification to your webhook. A webhook is a URL that is hosted on your site. Please contact if you would like to configure a webhook for your Cloudcheck site.

Cloudcheck expects a 2xx status code, e.g. 200, to be returned by your webhook. If a status other than 2xx is received it will be logged in our sytem.

The events that trigger a call to your webhook are:

  • A PEP match review is made in Direct (either for a verification for a ongoing monitoring request).
  • A review is made on a Live request in Direct.
  • A review is made on an IDscan request in Direct.
  • A review is made on an Akahu request in Direct.
  • A review is made on a Credfin request in Direct.
  • A review is made on a Document Check request in Direct.

We call your webhook using the POST method, passing a json payload that looks like this:

{
   "requestType": "<requestType>",
   "eventType": "<eventType>",
   "reference": "<reference>"
}

where:

  • <requestType> is either VERIFICATION, CAPTURE, IDSCAN, AKAHU, CREDFIN or DOCUMENT_CHECK.
  • <eventType> is either PEP_MATCH_REVIEW or REVIEW.
  • <reference> is a comma-separated list of references or tokens used to fetch the results using an API call.

For example, the json payload for a PEP match review would look like this:

{
   "requestType": "VERIFICATION",
   "eventType": "PEP_MATCH_REVIEW",
   "reference": "6e1c79ba-c9c0-4f74-b3d4-bdb3e0d85be2"
}

The json payload for a PEP match review for ongoing monitoring would look like this:

{
   "requestType": "WATCHLIST_MONITORING",
   "eventType": "PEP_MATCH_REVIEW",
   "reference": "0c78ee6c-5ef1-4772-a3b8-aab11869dd33,359505a039f0b80d3676ef61ab2dc332dd379a4bd87847055816d743245f61ec"
}

In this example the reference contains both the association reference and the match ID.