Closed pavlexander closed 3 months ago
Hi, the SpotV1 endpoints are deprecated and will be removed. SpotV3 and V5Api still work, with V5 offering the same functionality as SpotV3. V5 is the 'new' API, so that should be used when creating new things.
You're currently using a common client implementation, which is a interface which allows for some common functionality between different exchanges. If you want to access all functionality from the Bybit API you should instead use the V5Api.ExchangeData
endpoints. That will also solve you're issue with the timespan as it accepts an enum instead.
For the first issue, this is an API problem. They change the json structure based on that there is no data
few issues with an API
issue 1
returns error:
I think there is simply no data present/returned by the API, so the client should handle this gracefully as an empty list of whatever the data is returned, I think. Error should only be populated when there is an actual error with either an API request or other errors.
issue 2
because of issue 1 I started looking at other, more stable options, and found out that there are for some reason 3 api versions?
should the old versions be marked as obsolete maybe?
Regardless, I have tried running the same Klines endpoint with version 5 api (latest?):
but the issue I see here is that according to official documentation https://bybit-exchange.github.io/docs/v5/market/kline
the valid values for timespan are
Kline interval. 1,3,5,15,30,60,120,240,360,720,D,M,W
when you use a type of the parameter
TimeSpan
, then it's no longer possible to specify theMonth
(M
) as the input value. Months have variable number of days in them. It could be 29, 30, even 31. So it makes no sense so use the TimeSpan when working with klines/candles specifically.after running the above query I see that the
TimeSpan.FromDays(30)
was actually converted toM
valuethis is smart, but then what will I do if the exchange actually supports a 30 days period? Not sure if there is a point in overcomplicating things right now, but, if the current behavior translates the value of 30 to M then it should at least say so in the argument description I think..
so I would personally either change the parameter type, OR, simply update the existing parameter description with how the logic works in regards to Months etc.