Integrations
NautilusTrader uses modular adapters to connect to trading venues and data providers, translating raw APIs into a unified interface and normalized domain model.
The following integrations are currently supported:
| Name | ID | Type | Status | Docs |
|---|---|---|---|---|
| Betfair | BETFAIR | Sports Betting Exchange |  | Guide |
| Binance | BINANCE | Crypto Exchange (CEX) | | Guide |
| BitMEX | BITMEX | Crypto Exchange (CEX) | | Guide |
| Bybit | BYBIT | Crypto Exchange (CEX) | | Guide |
| Coinbase International | COINBASE_INTX | Crypto Exchange (CEX) | | Guide |
| Databento | DATABENTO | Data Provider | | Guide |
| dYdX | DYDX | Crypto Exchange (DEX) | | Guide |
| Hyperliquid | HYPERLIQUID | Crypto Exchange (DEX) |  | Guide |
| Interactive Brokers | INTERACTIVE_BROKERS | Brokerage (multi-venue) | | Guide |
| OKX | OKX | Crypto Exchange (CEX) | | Guide |
| Polymarket | POLYMARKET | Prediction Market (DEX) | | Guide |
| Tardis | TARDIS | Crypto Data Provider | | Guide |
- ID: The default client ID for the integrations adapter clients.
- Type: The type of integration (often the venue type).
Status
building: Under construction and likely not in a usable state.beta: Completed to a minimally working state and in a 'beta' testing phase.stable: Stabilized feature set and API, the integration has been tested by both developers and users to a reasonable level (some bugs may still remain).
Implementation goals
The primary goal of NautilusTrader is to provide a unified trading system for use with a variety of integrations. To support the widest range of trading strategies, priority will be given to standard functionality:
- Requesting historical market data.
- Streaming live market data.
- Reconciling execution state.
- Submitting standard order types with standard execution instructions.
- Modifying existing orders (if possible on an exchange).
- Canceling orders.
The implementation of each integration aims to meet the following criteria:
- Low-level client components should match the exchange API as closely as possible.
- The full range of an exchange's functionality (where applicable to NautilusTrader) should eventually be supported.
- Exchange specific data types will be added to support the functionality and return types which are reasonably expected by a user.
- Actions unsupported by an exchange or NautilusTrader will be logged as a warning or error when invoked.
API unification
All integrations must conform to NautilusTrader’s system API, requiring normalization and standardization:
- Symbols should use the venue’s native symbol format unless disambiguation is required (e.g., Binance Spot vs. Binance Futures).
- Timestamps must use UNIX epoch nanoseconds. If milliseconds are used, field/property names should explicitly end with
_ms.