Pagination

When necessary we use a pagination mechanism to fetch big volumes of data when the dataset is too large. For example, let's take a look at a call on the \ /transactions endpoint:

GET /transactions?page=2&page_size=5

Here, the API is queried to return the second page of our queryset, each page containing 5 elements Here is the resulting json:

{
  "edges": [
    {
      "cursor": 0,
      "node": {...}
    },
    {
      "cursor": 1,
      "node": {...}
    },
    {
      "cursor": 2,
      "node": {...}
    },
    {
      "cursor": 3,
      "node": {...}
    },
    {
      "cursor": 4,
      "node": {...}
    }
  ],
    "page_info": {
    "count": 73,
    "has_next_page": True
    }
}

There are two properties, edges and page_info, at the root level, explained in the following sections.

The edges Property

This property contains the relevant data as a JSON array. Each element of this array is an object with two properties:

• a cursor property which is an integer equivalent to the index of the element in the current view.

• a node property which represents the actual object being queried, in this case a Transaction type (whose schema is described in our openAPI specification).

The page_infoProperty

This property gives you the total number of objects contained in this particular queryset (count property), and allows you to know if the page you have queried is the last of a given view (has_next_page parameter).

About ordering

By default, results are sorted by creation date in descending order,newest objects being first.

We believe this makes search results more useful, but it can also be an issue when new objects are regularly added, as this could affect pagination, creating what looks like duplicates in two successive pages.

This is particularly relevant for transactions. If you were to successively fetch the first two pages of your transactions, and 20 new transactions were created between the two GET calls, then both responses would contain the exact\nsame results.

This issue can be avoided by making further use of filters (on accounts, creation date, etc.). We also recommend that you always de-duplicate by\nusing the object ids.