Fareclock paging lets clients retrieve large list results in smaller chunks by sending cursor, direction, and limit query parameters. When a response includes a cursor for the next page, reuse the same filters on every subsequent request and treat the cursor as an opaque value.

Some API List methods support paging in order to support larger data sets. Those API collections which do support paging are documented below in each collection under the List method documentation.

There are three optional query string parameters which are used to control paging:

• cursor: Inclusive value where to begin paged results, i.e., after where last page left off. Defaults to beginning or end of list, depending on direction.
• direction: 1 to list values after cursor, 0 to list values before cursor, depending on sort algorithm. Defaults to 1.
• limit: Number of results in page. Usually defaults to 25, and maximum 200.

If the result set was paged due to there being more items, the result set will contain a cursor value indicating where to begin the next page. The next page should be queried using this cursor value in query string. This cursor value should be treated as an opaque string, and not modified in any way. Also, each subsequent page request should contain the exact identical filter query parameters as the first page; otherwise, the paged data integrity cannot be guaranteed.

FAQ

Which query parameters control paging?

Use cursor to continue from a previous page, direction to choose forward or backward paging, and limit to set page size.

Can I change filters between paged requests?

No. Keep the filter query parameters identical across every page request. Changing filters while reusing a cursor can break result consistency.

Should I parse or modify the cursor value?

No. Treat the cursor as an opaque string returned by the API and send it back exactly as received.