Closed tonymorony closed 3 years ago
http://95.217.208.239:8080/api/v1/orderbook/KMD_USDT-BEP20 has more orders then http://95.217.208.239:8080/api/v1/orderbook/KMD_USDT, KMD_USDT is the correct one, USDT-BEP20 contains some duplicates. coinpaprika will work fine though, they query KMD_USDT ;-)
http://95.217.208.239:8080/api/v1/orderbook/KMD_USDT-BEP20 has more orders then http://95.217.208.239:8080/api/v1/orderbook/KMD_USDT, KMD_USDT is the correct one, USDT-BEP20 contains some duplicates. coinpaprika will work fine though, they query KMD_USDT ;-)
thanks for the report! I think that fixed that behavior. now if one of the tickers in the query contains -ERC20 or -BEP20 I'm checking only one order book without permutations (that's to have a way to get order book for specific protocol tokens if needed)
looks good, thanks for the fix
cf: https://github.com/tonymorony/dexstats_sqlite_py/issues/15
@cipig I've added more logic into order book call to parse more liquidity across the protocol for the CEX aggregators
now if let's say you call http://95.217.208.239:8080/api/v1/orderbook/KMD_USDC API will try to get and combine all mm2 orderbooks variations bids and asks such as:
KMD / USDC
KMD-BEP20 / USDC KMD-ERC20 / USDC
KMD / USDC-ERC20 KMD / USDC-BEP20
and provide it as a call result
could you please check if it works on stage http://95.217.208.239:8080/api/v1/orderbook as expected? if everything looks fine I'll update the production endpoint with these changes