Pagination, sorting, and filtering

You can control what and how data is returned from the Monite API by using the following techniques:

• pagination
• sorting
• filtering

Pagination

Pagination is a process of dividing the resulting set of data into discrete blocks of information (pages). It decreases both the server payload and the network traffic and increases the speed of page loading.

For example, in Monite you may have 1000 Payables registered and want to receive them in groups of 1-100, where 100 is the maximum of documents that can be requested at a time.

Pagination cursor field

For pagination to work, one field (column) in the database table must be selected as a pagination cursor field. By default, the pagination cursor uses the created_at field. Every database table has such a field, so there is no need to specify it explicitly, unlike other cursor fields. Allowed pagination options for the cursor fields are defined for each endpoint independently, see the details in the Reference section.

Pagination is based on just one cursor field and this field cannot be changed during the pagination process. Let's say we have a table with the id, first_name, last_name, email, phone, and created_at fields. If the pagination is initiated with the first_name field, the API consumer won't be allowed to modify the cursor field in/for the second page.

Page size (limit)

To avoid server and network overloading, the number of returned records in GET requests is restricted. In API requests the limit query parameter defines the number of records that the API consumer wants to receive in the response. Possible values are 1 to 100. Values outside of this range will result in the HTTP error 416 (Requested range not satisfiable).

Sorting

Besides selecting a pagination cursor field, you can use the order query parameter to define the order in which the returned records are sorted: asc (ascending) or desc (descending). Default is asc.

Filtering

Very often API consumers may want to retrieve only selected records rather than all available sets of records. For example, a user is interested only in Payables created 10 days ago or later. To achieve this, you can provide filters in the request query string.

Filters can be of two types:

• Exact match (case-sensitive):

  FIELD=VALUE
  

  For example, name=Acme or price=1000.

• Comparison filters:

  FIELD__OPERATOR=VALUE
  

  For example, created_at__gte=2022-01-01T00%3A00%3A00 returns items created on or after January 1, 2022. See the list of operators below.

Multiple filters can be combined using & (logical AND).

📘

The supported filter fields and operators vary per endpoint. Refer to the endpoint reference for the exact supported filters.

Filter operators

Query examples

• No filters. Only the cursor, sorting, and limit fields are specified:

  GET /products?limit=10&cursor_field=was_created_by_user_name&order=desc
  

• Filtering by date and limiting the result set:

  GET /products?limit=2&created_at__gte=2021-10-05T00:00:00
  

• Filtering by two fields with the default pagination:

  GET /products?limit=10&was_created_by_user_name=Andrew&status=active
  

Response example

If the data is selected based on the specified conditions, the response will look like this:

{
    "data": [
      // array of records
      { ... },
      { ... },
      ...
    ],
    "prev_pagination_token": "bGltaXQ9MiZmaXJzdF9vaWQ9MSZwcmV2X3Rva2VuPTM=",
    "next_pagination_token": "bGltaXQ9MiZmaXJzdF9vaWQ9MSZuZXh0X3Rva2VuPTQ="
}

The next_pagination_token and prev_pagination_token values can passed in the pagination_token query parameter to receive the next or previous page in the result set.

Error codes

When something goes wrong with pagination or filtering, one of the following HTTP response codes is returned:

• 406 Not Acceptable
• 416 Range Not Satisfiable