After downloading the income history of several different api keys, I found interesting cases.
After downloading from the beginning to the end of all records without specifying the type, on some keys the discrepancy is 1 USDT and on some as much as 100 USDT the difference with the real balance. (the longer the story, the greater the difference).
How is this possible? Does Binance store more than 8 decimal and do rounding for api? already posted a problem with incorrect rounding in income here, is this still a thing?
I’m using GET /fapi/v1/income and skip all non USDT records. For storage I’m using decimal(16,8) so no rounding applied and sum calculating correctly.
How did you query /fapi/v1/income? Did you start from the beginning of your future account creation and do a loop until you get every records? And is it possible that you could have more than 1000 recs in the same millisecond?
Yes, I do start from beginning till the end. In loop.
One api key is quite small and hand traded so no, 1000 records per millisecond is not possible. Other one maybe. But I really believe the problem with rounding. Because the longer history the more difference.
To exclude any error on my side I do have unique check per type/trandId,I’m using decimal to proper calculate SUM without float rounding issues.
Also hint for you. Its appear on accounts with REFERRAL_KICKBACK records.
(Funny story on docs its only 6 types of income, but in reality only god knows how many, for example: OPTIONS_PREMIUM_FEE, REFERRAL_KICKBACK)