Pagination
The Partner API supports cursor-based pagination, allowing you to request just a subset of records. Each record in the response is assigned a cursor (or position), enabling the client to navigate forward or backward through the recordset, rather than retrieving thousands of records in a single response.
The response includes a pageInfo object, which contains fields such as hasNextPage, hasPreviousPage, startCursor, and endCursor. Using this information, the client can determine whether more records are available in either direction.
This improves performance and efficiency for both the client and the server by reducing payload sizes, lowering memory usage, and speeding up response times. It also gives you more control over how and when data is requested.
Below is an example of how to use paging to return 2 bets per page. Obviously in practise you will likely return a much higher number per page but this allows us to show you a complete request / response:
The initial request is for the first 2 bets. No after has been specified since we want to start at the beginning (most recent bet)
{
"data": {
"bets": {
"pageInfo": {
"startCursor": "NQ==",
"endCursor": "NA==",
"hasNextPage": true,
"hasPreviousPage": false
},
"totalCount": 5,
"edges": [
{
"cursor": "NQ==",
"node": {
"toteId": "862fe312ea69498ab70260cb9f619e67"
}
},
{
"cursor": "NA==",
"node": {
"toteId": "b94c44263fea41c488db1db53bf32791"
}
},
]
}
}
}
Notice that the response contains a pageInfo object with pagination information that can be used to make subsequent requests. In this case we see that hasNextPage is true indicating that there is another page of data to fetch and that the endCursor for the current page is "NA==". We've also included a totalCount so we can see how many records there are in total across all pages. It's also possible to see the cursor for each individual record by requesting the edges as shown.
The second request is for the first 2 bets after the endCursor from the previous request. i.e. "NA=="
{
"data": {
"bets": {
"pageInfo": {
"startCursor": "Mw==",
"endCursor": "Mg==",
"hasNextPage": true,
"hasPreviousPage": true
},
"totalCount": 5,
"edges": [
{
"cursor": "Mw==",
"node": {
"toteId": "505b6592cbc04945bf723473250bc3ec"
}
},
{
"cursor": "Mg==",
"node": {
"toteId": "b969fdb74e724b6784ac048473a0b5ba"
}
},
]
}
}
}
Notice that the pageInfo object now shows hasPreviousPage is true as well as hasNextPage, so it's possible to navigate back to the previous page if desired. The third request is for the first 2 bets after the endCursor from the previous request. i.e. "Mg=="
Finally you can see that hasNextPage is now false indicating that there are no more pages to request if paging forwards. The forth request shows how to page backwards. This time, we need to request the last 2 bets before the startCursor. If we requested the first 2 bets before the startCursor, we'd retrieve the first 2 bets in the recordset and be back at the first page.
{
"data": {
"bets": {
"pageInfo": {
"startCursor": "Mw==",
"endCursor": "Mg==",
"hasNextPage": true,
"hasPreviousPage": true
},
"totalCount": 5,
"edges": [
{
"cursor": "Mw==",
"node": {
"toteId": "505b6592cbc04945bf723473250bc3ec"
}
},
{
"cursor": "Mg==",
"node": {
"toteId": "b969fdb74e724b6784ac048473a0b5ba"
}
},
]
}
}
}