Pagination not working for getting "previous" (more recent) trades

Hello! I am trying to access historical trade data through the REST API. When testing, I noticed that there was an issue when the before is given, but not the after (regardless of whether limit is given); namely that the before is ignored, and the most recent data are retrieved. The same issue does not occur if after is given, but not before.

The idea here is that I want to get some data from awhile ago, do stuff, then get more data: basically simulate how some code would work if it were run “live” in the past.

This REST endpoint works without authorization, but the issue seems to persist when authorization is given in the full GET command, as well.

The following URLs will return the 9 BTC-USD trades with ids 300000001-300000009:

However, the following URL will return the last 9 trades

similar to the output when before is not given

Duct-tape solution
For getting trades, it is easy enough to just set after=before+limit+1 and then send the request with before and after. However, this is not particularly elegant or robust.

For example, let’s say that I am asking for the first 2 available trades after trade id 100 for some product (with >>102 trades). However, it turns out that trade 102 was lost, so before=100&after=103 will only return trade 101, while before=100&limit=2 should return 101 and 103. This is a pretty minor issue and most code should be able to handle either case. However, if you want to see how far back historical data goes, trying out before=0&limit=1 would be useful.

The other issue with this is that not all paginated data uses an integer to mark the page. For example Get all orders uses an ISO 8601 timestamp. I would like to have my code be a bit more consistent/flexible so that I do not have to guess how to “add” numbers to the page markers. Plus, I am not having this issue with the /orders endpoint.

One thing that would be useful is some way of getting the trade id around a given time. With the current set up, I basically do a fancy binary search for this (leading to a couple dozen unnecessary calls).

1 Like

Hi @Magi, thank you so much for participating in the forum. This is a valid concern and we were able to replicate the issue. We are now investigating this issue further and we’ll get back to you once we have more information.