Pagination / Sorting / Filtering / Types

Filtering Data

When retrieving lists of data, you can use ordinary request parameters to filter or sort the data, or control pagination.

LIKE filtering

Some keywords and text fields allow for substring / like searches... 

By default, all searches for a LIKE field, will be treated as substring searches, with wildcards added to the search term before/after the text provided.

Any spaces will be converted to wildcards. 

For example searching for "hip mus" would find both "hippopotamus" and "hip music"

The official wildcard characters are % and _ for a single character transition. 

matchType filtering

You can use an additional parameter matchType in some endpoints. Possible matchType values:
IN, ILIKE, LIKE, <=, >=, <, >, <>.
When using the IN matchType please provide the values as comma separated. Example name=100,200,150


You may control the pagination of long lists by providing the following request parameters. Values should be integers and greater than 0. The total row count may or may not be provided, depending on the end point. There is no pagination on file lists, but for faster response times on a website, you should aim to have less than 1000 files per directory.

Offset=200   (Default 0)

PageSize=200   (Default 200, max 1000 rows) 

Sorting Data

Please add a "orderBy" parameter, with one of the following values: "Created,Code,Name,LastModified" 

More options may be available for some end points. By default, created date is the default order

You can reverse the order by adding another parameter: orderDirection=reverse

Null Values

Our APIs generally will not return NULL values. For a reduced bandwidth, and easier debugging, we only include attributes with values. Your consuming client applications should cope with the non existence of a field, treating no key as a null, not an exception.

Date Values

We prefer the format yyyy-MM-dd HH:mm:ss, but you can use most common API date formats, and we will do our best to parse those dates. Please avoid using d/m/y or m/d/y dates for obvious reason, that we cannot be sure which is which. 

Date values are provided in a string format in JSON


Some decimals are available to 3 decimal points, including some prices and quantities. Most others are 2 decimal points. Rounding should occur automatically if you provide 

You can supply decimals as text, but may throw an error if not valid format


Our interface provides most booleans as text "t" or "f" or null, some boolean values are presented as a clean json boolean eg "true". Please ensure your interface can accept "t" or pure Boolean answers interchangeably, as this mainly relates to a legacy bug, and many legacy boolean fields being stored as single chars in the database.

We can accept booleans as pure booleans like true,false or as text like so: T,F,1,0,t,f,Y,N