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
AX Exchange	AX	Perpetuals Exchange		Guide
Betfair	BETFAIR	Sports Betting Exchange		Guide
Binance	BINANCE	Crypto Exchange (CEX)		Guide
Coinbase	COINBASE	Crypto Exchange (CEX)		Guide
BitMEX	BITMEX	Crypto Exchange (CEX)		Guide
Bybit	BYBIT	Crypto Exchange (CEX)		Guide
Databento	DATABENTO	Data Provider		Guide
Deribit	DERIBIT	Crypto Exchange (CEX)		Guide
dYdX	DYDX	Crypto Exchange (DEX)		Guide
Hyperliquid	HYPERLIQUID	Crypto Exchange (DEX)		Guide
Interactive Brokers	INTERACTIVE_BROKERS	Brokerage (multi‑venue)		Guide
Kraken	KRAKEN	Crypto Exchange (CEX)		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

• planned: Planned for future development.
• 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.