Pagination bm-before > bm-after when sending "after={BM-AFTER}"

[smiley1983]

For context, I'm using API v3 to fetch candles for e.g. BTC-AUD. The endpoint is /v3/markets/BTC-AUD/candles.

When sending ?before={BM-BEFORE}, it behaves as expected. For example, see the headers returned by this link:

https://api.btcmarkets.net/v3/markets/BTC-AUD/candles?before=1605484800000

They contain this data:

bm-after = 1605484800000
bm-before = 1588291200000

However, if I pass ?after={BM-AFTER}, the resulting bm-after in the headers is smaller than bm-before:

https://api.btcmarkets.net/v3/markets/BTC-AUD/candles?after=1605484800000

The headers contain this data:

bm-after | 1605484800000
bm-before | 1622678400000

It's easy enough to work around the issue (I'm just using the larger number when passing ?after= and the smaller number when passing ?before=, but it seems inconsistent with the documentation, which says:

• If you need to retrieve older records, then pass before=1234567 as query string with 1234567 being the value of HTTP header BM-BEFORE.

• If you need to retrieve newer records, then pass after=123589 as query string with 123589 being the value of HTTP header BM-AFTER.

If I do as the documentation says, and iteratively pass after={BM-AFTER} to try to fetch newer pages, I actually get the same page over and over again.

[martin-nginio]

Hi @smiley1983

Thanks for reaching out and reporting this issue.

The candle API support two different ways of data pagination and I can confirm the issue reported is valid and the data returned does not have our standard sorting (always descending) hence the after parameter returned via http header is not correct.

given the API is public we may provide a new API or a similar solution to fix this issue. I will update this ticket as soon as the issue is fixed.

As a workaround, please use the timestamp returned by the last item in the list (if using after) and that should allow you to use the pagination.

Thanks.

Regards, Martin