# pybit: a small Bybit connector for HTTP and WebSocket trading

> pybit is Bybit's official Python connector, kept deliberately light on dependencies so that it pulls in requests, websocket-client and pycryptodome and little else. It exposes a unified trading session for both HTTP and WebSocket calls, and the author of the original version says the whole point was to avoid the pile of transitive modules that generated connectors tend to bring.

**bybit-exchange/pybit** — Official Python3 API connector for Bybit's HTTP and WebSockets APIs.

- Repository: https://github.com/bybit-exchange/pybit
- Stars: 672 · Forks: 8
- Language: Python
- License: NOASSERTION
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/bybit-exchange-pybit

## A connector built to avoid the dependency pile

The origin story is in the README, in a block quoted from the author who created the library, Verata Veritatis, and it explains the design better than any feature list would. The quote complains about auto-generated connectors that used what it calls a mosh-pit of various modules you did not want, naming bravado as an example, and states the goal of building a Python3-dedicated connector with very little external resource.

The dependency list confirms that goal was met. The requirements.txt file contains three entries: requests, websocket-client and pycryptodome, with the websocket client pinned to 1.5.0 and pycryptodome to 3.20.0. The setup.py lists the same three in install_requires. There is no asyncio framework, no ORM, no data validation library, no retry library, and no HTTP framework.

That is a real design position rather than an accident of age. It means the module drops into an existing environment without dragging a conflicting version of anything, and it means when a dependency does have a security advisory you have three places to look rather than thirty.

It also means the convenience that a heavier library would provide is absent. There is no built-in retry with exponential backoff, no connection pool configuration, no structured error hierarchy beyond what the HTTP layer gives you, and no async variant. If your strategy needs any of that, you write it, and the examples directory is where the maintainers put the patterns for doing so.

The library is described as the official lightweight one-stop-shop module for the Bybit HTTP and WebSocket APIs, and it is now maintained by Bybit employees, though outside contributions are still welcome and the development section says new Bybit API changes should arrive quickly.

## One session object covers HTTP, WebSocket and P2P

The usage section opens with an import and a session:

```python
from pybit.unified_trading import HTTP
```

```python
session = HTTP(
    testnet=False,
    api_key="...",
    api_secret="...",
)
```

The name of the import is the design. It is a unified trading session, and the same object carries the REST calls and the stream subscription calls, with the category argument on each method telling the API which product you mean. The first example is an orderbook read:

```python
# Get the orderbook of the USDT Perpetual, BTCUSDT
session.get_orderbook(category="linear", symbol="BTCUSDT")
```

The category argument is the vocabulary of Bybit's own API, and it appears on every call: linear for the USDT perpetuals, inverse for the coin margined ones, option for options, spot for spot. A client that forced you to create a separate object per product would be more type-safe, but it would also mean four objects and four credential sets in every script.

The testnet flag is the other thing to set immediately. Setting testnet=False against a real account while you are still writing the code is how a test order becomes a real order.

P2P methods come from the same session, which is worth noticing because P2P, the peer to peer fiat trading feature, is a separate product with its own endpoints:

```python
session.get_account_information()
session.get_ads_list()
```

The examples directory makes the range visible: direct_session.py, http_example_quickstart.py, http_example_explanatory.py, http_example_rsa_authentication.py, the p2p equivalents, the websocket quickstart and explanatory examples, websocket_http_example_spread_trading_quickstart.py, websocket_trading_example_quickstart.py, websocket_unsubscribe_example.py and wrapper_class.py. That last one is interesting on its own, because a wrapper class over the session is the pattern you would build yourself if you wanted to configure the client once and inject it.

## Bulk order submission, and the one product that allows it

The order example in the README carries a caveat in a comment that is worth reading twice, because it is the kind of restriction that bites in production.

```python
# Create five long USDC Options orders.
# (Currently, only USDC Options support sending orders in bulk.)
payload = {"category": "option"}
orders = [{
  "symbol": "BTC-30JUN23-20000-C",
  "side": "Buy",
  "orderType": "Limit",
  "qty": "0.1",
  "price": i,
} for i in [15000, 15500, 16000, 16500, 16600]]

payload["request"] = orders
# Submit the orders in bulk.
session.place_batch_order(payload)
```

The method is place_batch_order, and at the time of writing only USDC Options support sending orders in bulk. The category has to be option and the instrument has to be a USDC-settled option, so the feature is narrower than the method name suggests. If you are trading perpetuals and want to place a ladder of orders, you are looping and calling place_order yourself, and you are on the hook for what happens when one of those calls fails halfway through.

The payload shape is also worth reading as a schema. The list of orders goes under a request key, the category sits alongside it, and each order is a plain dict with symbol, side, orderType, qty and price. That is the API's own shape passed straight through, which is the general pattern in this library: the connector is thin, and the request body is yours to construct.

The price values in the example are 15000 through 16600 in steps, which is a price ladder, and each order carries a fixed qty of 0.1. Note that the option symbol encodes an expiry and a strike, BTC-30JUN23-20000-C, and the price is the premium. The instrument naming convention is Bybit's and the library does not abstract it.

## WebSocket examples are the place to look before going live

The README does not have a WebSocket code block, and that is not an oversight so much as a pointer. The usage section says to check out the example python files or the list of endpoints below, and that usage examples on the HTTP methods can be found in the examples folder.

That phrasing is a bit loose, but the practical advice is clear enough: the streaming side is documented by example rather than by prose, and there are several of them. The websocket_example_quickstart.py and websocket_example_explanatory.py files are the entry points, websocket_unsubscribe_example.py handles teardown, and websocket_trading_example_quickstart.py is the one that places orders from a stream.

The file names themselves tell you what the connector does not abstract. There is a spread trading example that combines HTTP and WebSocket, and a wrapper_class.py that shows the pattern for configuring a session once and reusing it.

What you will not find in the documentation is guidance on the operational questions that decide whether a live bot survives a week. How often to reconnect after a drop, whether the client resubscribes automatically, what the rate limits are, how the ping and pong frames are handled, and what happens to an in-flight order when the socket closes. Some of that may be handled and simply not documented, which is a good reason to read the source of the websocket module before you rely on it.

The three dependencies tell you the shape of the implementation. websocket-client is a synchronous, threaded library, so the streaming side is a background thread feeding a queue, not an async generator. That is a legitimate design for a trading bot, and it has an important consequence: your event loop and the socket's thread are separate, and the ordering of messages relative to your own logic is something you define rather than something the library defines for you.

## Version requirements, licensing and the support channel

The installation section is short. pybit requires Python 3.10 or higher, and it can be installed manually or via PyPI with pip:

```bash
pip install pybit
```

The setup.py agrees, with python_requires set to >=3.10, and the classifiers list Python 3.10 and 3.11. The version number itself comes from the package rather than being duplicated, imported as VERSION from pybit, which is a small thing that avoids the classic setup.py and package version drift.

On the licence there is something to notice. The setup.py declares license as MIT License, and the classifier is the MIT OSI approved licence, but the repository's own licence field is recorded as a custom licence that GitHub cannot classify. The LICENSE file at the repository root is the authoritative text, and if the terms matter to you for a commercial deployment, read that file rather than the metadata.

The release history shows a steady cadence with a gap. The recent versions are 5.16.0 from 2026-04-18, 5.15.0 from 2026-04-11 and 5.14.0 from 2026-02-06, and the last push to the repository was on 2026-10-14, with the project not archived. So the source is being worked on more recently than the newest published release, and the version in production may be behind what is in the tree.

Support runs through the exchange's own channels rather than the issue tracker: a Telegram group chat and a Discord server. That is a reasonable arrangement for an official connector, since API questions are usually about the API rather than about the library, but it does mean the library's own bug reports go through the repository, and the README says the aim is an active issue and discussion board leading to consistent improvements.

The top level of the repository is a conventional Python package layout: the pybit/ package, an examples/ directory, tests/, setup.py, setup.cfg, a requirements.txt, a MANIFEST.in, a CHANGELOG.md and a.travis.yml, an older CI configuration file that still sits at the repository root.

## Conclusion

Adopt pybit if you are writing a trading bot or research script against Bybit and want the official connector rather than a generated one, and if you value a small dependency tree. Do not adopt it for a long-running high-frequency execution service without reading the WebSocket examples first, because the connector's own documentation is organised around a session object and a set of examples rather than around retry, reconnect and rate-limit handling, and the library does not document those. Before you commit, confirm you are on Python 3.10 or newer, set testnet=True while you build the strategy, and read the trading and unsubscribe examples in the examples folder, because order placement and stream management are where the sharp edges are.

## FAQ

### What does pybit depend on?

Only requests, websocket-client and pycryptodome, with the websocket client pinned to 1.5.0 and pycryptodome to 3.20.0 in requirements.txt. The design goal stated by the original author was a connector with very little external resource, avoiding the pile of modules that generated connectors tend to bring.

### How do I create a pybit session and query the orderbook?

Import HTTP from pybit.unified_trading, create a session with HTTP(testnet=False, api_key, api_secret), then call session.get_orderbook(category="linear", symbol="BTCUSDT"). The category argument selects the product, so linear is the USDT perpetuals.

### Which products support bulk order submission in pybit?

The README states that currently only USDC Options support sending orders in bulk. The method is session.place_batch_order, with the category set to option and the list of orders placed under a request key in the payload.

### What Python version does pybit require?

Python 3.10 or higher. The README states the requirement, setup.py sets python_requires to >=3.10, and the classifiers list Python 3.10 and 3.11. Installation is with pip install pybit.

### Where can I find pybit WebSocket examples?

In the examples directory of the repository, which includes websocket_example_quickstart.py, websocket_example_explanatory.py, websocket_unsubscribe_example.py and websocket_trading_example_quickstart.py, plus wrapper_class.py for the pattern of configuring a session once and reusing it.

## Sources

- [bybit-exchange/pybit on GitHub](https://github.com/bybit-exchange/pybit)
- [Issues](https://github.com/bybit-exchange/pybit/issues)
- [README](https://github.com/bybit-exchange/pybit/blob/master/README.md)
- [Releases](https://github.com/bybit-exchange/pybit/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/bybit-exchange-pybit