1. All Collections
  2. API
  3. General structures and principles
Image

General structures and principles

General structure of API requests and responses.

Avatar

By Support Core

April 13, 2026

Below is the general structure of the APIs.


Response Types

Code Response Description
200 OK Successful call and response body should generally be a JSON document or JSON collection. Can be null if no record is found.
400 Bad Request Likely a problem with your data or missing values.
401 Unauthorised Likely your credentials didn't match your login.



GET

Get methods are available to get either a specific object or collection of an object. At times due to considerations of speed (such as with equipment types) a restricted view of the object collection is available.

GET /equipmenttypes

GET /equipmenttypes/999



PUT

Where available a PUT method will allow the creation of an object. It is generally easiest to call a GET first to view the full field list about the values that can be supplied. Note that some of the values supplied are readonly, such as clientId, modifiedBy, etc.

The PUT command is rerunable. This means if an importuniqueid is supplied and there is already an existing record matching this importuniqueid, it will be updated instead of created. This is implemented for clients, client locations, equipment, and parts.

PUT /clients

Request body example:

[{
  "name": "client1",
  "ContactFirstName": "site manager"
}]



PATCH

Where available the PATCH command allows you to update specific fields or objects. The structure of the command does not require the operation command and simply accepts a path (field) and value for each required field update. Multiple operations can be applied at once.

The below example is how to update the contact first name for a particular client.

PATCH /clients/{xxxx-xxxxxxx-xxxxxxxxx-xxxx}

Request body example:

[{
  "path": "ContactFirstName",
  "value": "new site manager"
}]



Pagination

Some endpoints support pagination to manage large result sets. When available, you can control the page of results returned using query parameters.

The following endpoints support a pageNo parameter and return a maximum of 200 items per page:

  • GET /Jobs
    GET /Jobs?statusid=6&dateFrom=2025-01-01&pageNo=2
  • GET /Equipment
    GET /Equipment?locationId=xxxx-xxxx&pageNo=2
  • GET /Inspections
    GET /Inspections?modifiedDt=2025-06-01T00:00:00&pageNo=2
  • GET /ServiceRecords
    GET /ServiceRecords?modifiedDt=2025-06-01T00:00:00&pageNo=2

GET /Reports supports pageNumber and pageSize parameters. pageSize controls how many records are returned per page.

GET /Reports?reportName=All Inspections by Month&month=9&year=2025&pageSize=50&pageNumber=1

If no pagination parameters are supplied, the endpoint will return the first page of results using its default page size. To retrieve all records, continue requesting the next page number until fewer results than the page size are returned.

Pagination Response Headers

GET /Equipment, GET /Inspections, and GET /ServiceRecords include the following response headers to indicate the total size of the result set:

Header Description
X-Total-Count The total number of matching records across all pages.
X-Total-Pages The total number of pages (at 200 records per page).

The response body remains a plain JSON array. These headers allow you to determine how many pages to iterate through without changing how you parse the response data.



Change Tracking (modifiedDt)

Most GET collection endpoints accept an optional modifiedDt query parameter that filters results to records modified on or after the supplied datetime. This is useful for syncing changes since a previous poll.

Optional on: Clients, Branches, Equipment Types, Parts, Equipment, Jobs.

Required on: Inspections, Service Records (to prevent full-table scans on large datasets).



Delete

There is no delete method as all data is system retained, but simply using the PATCH command setting isActive to false achieves the same result.

IMAGE