USD-M Income History - Timestamp pagination resulting in an infinite loop when more than 1000 trades have the same timestamp


I’m retrieving USD-M Futures Income History data for a high frequency trader through this endpoint:
GET /fapi/v1/income (HMAC SHA256)

I’m currently paginating with timestamp - Getting the first 1000 trades, taking the last timestamp and getting the next batch etc. This works perfectly in most cases, however at a certain point I encounter more than 1000 trades which have the same timestamp. This results in my code taking the last timestamp and trying to get the next batch which returns the same list over and over again.

If I change the timestamp to a second later, it gets out of the loop but it will miss any other transactions with that timestamp.

I was hoping that another parameter could be added such as tradeId or tranId to query with which would resolve this issue.


Hi Luke,

The team is aware of this request however a decision is yet to be taken.

For the time being if you encounter this state, I suggest introducing an additional filter by incomeType and revert back the filter once you handle the state.

1 Like

Hi Alex,

Thanks, will try to get around it using your method for the time being.

1 Like

Hi Alex,

I’ve tried your solution and unfortunately I encountered the same issue. There is over 1000 transactions with the same timestamp and the same incomeType (Realized_Pnl).

There are two way forwards for the time being

  • Add or replace the incomeType filter with a symbol filter. Understandably this will increase the number of requests required significantly.
  • Generate an income report via the Binance UI.
1 Like

This is not possible with virtual sub-accounts though.
We have a similar issue with customers having a lot of future transactions.

If the timestamps were not rounded to the second, it would probably mitigate this issue and improve the data quality at the same time.