Mapping library naming to bybits?

[mmaestrini]

Hi Tiago,

how does one map your naming convention to bybits? For instance in LinearConditionalOrderRequest, you have price, and base_price, but i cannot seem to see what Bybit's naming for these are.

Also was wondering what the difference between the linearClient and RestClient is for the purpose of opening a trade? whether a market or limit order in perpetuals usdt.

[Tiago]

Hey @mmaestrini

For the REST API functions designed to take an object, the naming is exactly the same as what the bybit api docs state.

In your example, LinearConditionalOrderRequest is from the LinearClient's placeConditionalOrder() method.
https://github.com/tiagosiebler/bybit-api/blob/master/src/linear-client.ts#L235-L239

This is mapped to the private/linear/stop-order/create endpoint from V2 linear (usdt perp) APIs:
https://bybit-exchange.github.io/docs-legacy/futuresV2/linear/#t-placecond

This brings me to your latter question. Bybit has quite a few API groups and the older groups, which are essentially previous generations of their API, can be a bit confusing at first.

Each API group has a dedicated section in Bybit's API docs as well. I've added a table to the readme of this SDK over here, listing the API groups and the corresponding sections in Bybit's API documentation, as well as the name of the class in this SDK to interact with each API group:
https://github.com/tiagosiebler/bybit-api#rest-api-clients

The LinearClient maps to Bybit's V2 USDT Perp APIs, which were previously called "linear futures" in their documentation. This is where you'll see request properties matching the properties in the API docs. All these V3 and older API groups should now be considered legacy, since the release of the V5 APIs, which should cover most of the previous use cases in one unified and modernised API.

This is what the RestClientV5 is for. It maps to the all-in-one V5 APIs. These are the endpoints you're probably looking at in the API documentation as well, since this all shows the V5 endpoints by default. Their docs also give a nice overview of the new V5 APIs vs the previous groups:
https://bybit-exchange.github.io/docs/v5/upgrade-guide

If you're starting or have recently started a new integration with bybit, it's definitely recommended to work with the V5 APIs instead of the legacy APIs if you can. If you do find anything missing (but it's shown in the docs), PRs are welcome or open an issue here.

If you've been working with the older APIs for some time, there's no immediate urgency in moving to the V5 APIs, but it's recommended to evaluate transitioning to V5 in the coming months.

Lastly, almost all the added endpoints are relatively strongly typed. Although it's not required and pure JS is fine, your integration efforts will be much easier if you're using typescript (or even an IDE that can understand types like VSCode), since it'll give you feedback if you're passing unexpected types to some of these functions (e.g. passing an object instead of a string).

[mmaestrini]

Wow really amazing and elaborate answer. Thank you so much dude and thank you for your work.

I have never worked with ByBit before and now that I understand I will definitely only work with the v5!

Regarding the typing, yes I use TS and NESTJS, but unfortunately, I don't seem to be able to get the types / intellisense. Not sure why.

Also i need to use require vs import or i get this error:

ERROR ...../bybit/services/bybit.service.ts(123,35)
      TS2345: Argument of type '{ key: string; secret: string; testnet: boolean; market: string; }' is not assignable to parameter of type 'WSClientConfigurableOptions'.
  Types of property 'market' are incompatible.
    Type 'string' is not assignable to type 'APIMarket'.

I think it's get easier if i can get intellisense and browse to your library so I wont have to ask more annoying questions :D I'll see around if i find out what's the deal - but if you have any idea, id certainly appreciate.

[mmaestrini]

just for anyone else, I kept using require for the websocket but I used import for Restclient and all is good with intellisense :)

[Tiago]

Glad you found it! Yes, imports are the way to go if you're using TS. There might be some request/response types for less common methods that are incomplete or missing (any). If you find any that you need, I'd certainly welcome a PR to add those too!