How NautilusTrader Normalizes Exchange and Data Provider Integrations
Article NautilusTrader
Summary
This reference explains how NautilusTrader connects to exchanges, brokerages, and data providers through modular adapters. It lists supported integrations and their categories and stability labels, then outlines the common functions these adapters are intended to provide: historical and live market data, execution-state reconciliation, and standard order submission, modification, and cancellation. It also describes a design goal of matching low-level venue APIs while presenting users with a consistent system interface.
The document gives implementation conventions for normalized symbols and nanosecond timestamps, while allowing explicit millisecond field names where needed. It notes that exchange-specific functionality may vary and unsupported actions should produce warnings or errors. The integration status labels indicate maturity, with stable meaning tested to a reasonable level rather than guaranteed bug-free. TRACE logs may expose authentication data in raw WebSocket messages, so the guide limits their use to local debugging and recommends redaction before sharing. This is architecture and operational guidance, not a trading strategy or evidence of trading performance.
Key ideas
- Adapters translate venue and data-provider APIs into NautilusTrader’s shared model.
- The standard integration goals include historical and live data, execution reconciliation, and common order operations.
- Symbols generally retain venue-native formats, with disambiguation where needed.
- Timestamps use nanoseconds unless the field name clearly indicates milliseconds.
- Stability labels describe maturity, and stable integrations may still contain bugs.
Tags
Full text
# Integrations # 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](https://architect.exchange) | `AX` | Derivatives Exchange |  | [Guide](architect_ax.md) | | [Betfair](https://betfair.com) | `BETFAIR` | Sports Betting Exchange |  | [Guide](betfair.md) | | [Binance](https://binance.com) | `BINANCE` | Crypto Exchange (CEX) |  | [Guide](binance.md) | | [Coinbase](https://coinbase.com) | `COINBASE` | Crypto Exchange (CEX) |  | [Guide](coinbase.md) | | [Blockchain](blockchain.md) | `BLOCKCHAIN` | DeFi Data Provider |  | [Guide](blockchain.md) | | [Bybit](https://www.bybit.com) | `BYBIT` | Crypto Exchange (CEX) |  | [Guide](bybit.md) | | [Databento](https://databento.com) | `DATABENTO` | Data Provider |  | [Guide](databento.md) | | [Deribit](https://www.deribit.com) | `DERIBIT` | Crypto Exchange (CEX) |  | [Guide](deribit.md) | | [Derive](https://www.derive.xyz) | `DERIVE` | Crypto Exchange (DEX) |  | [Guide](derive.md) | | [dYdX](https://dydx.trade) | `DYDX` | Crypto Exchange (DEX) |  | [Guide](dydx.md) | | [Hyperliquid](https://hyperliquid.xyz) | `HYPERLIQUID` | Crypto Exchange (DEX) |  | [Guide](hyperliquid.md) | | [Interactive Brokers](https://www.interactivebrokers.com) | `INTERACTIVE_BROKERS` | Brokerage (multi-venue) |  | [Guide](interactive_brokers.md) | | [Kraken](https://kraken.com) | `KRAKEN` | Crypto Exchange (CEX) |  | [Guide](kraken.md) | | [Lighter](https://lighter.xyz) | `LIGHTER` | Crypto Exchange (DEX) |  | [Guide](lighter.md) | | [Lighter on Robinhood](https://robinhoodchain.lighter.xyz) | `LIGHTER_ROBINHOOD` | Crypto Exchange (DEX) |  | [Guide](lighter.md) | | [OKX](https://okx.com) | `OKX` | Crypto Exchange (CEX) |  | [Guide](okx.md) | | [Polymarket](https://polymarket.com) | `POLYMARKET` | Prediction Market (DEX) |  | [Guide](polymarket.md) | | [Tardis](https://tardis.dev) | `TARDIS` | Crypto Data Provider |  | [Guide](tardis.md) | - **ID**: The default client ID for the integrations adapter clients. - **Type**: The type of integration (often the venue type). For Lighter on Robinhood, `LIGHTER_ROBINHOOD` is the venue and explicit client ID to register. The shared Lighter factory keeps `LIGHTER` as its compatibility default. ## 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. ::::warning[Trace logging and credentials] TRACE logs may include raw outbound WebSocket payloads, which can contain authentication data for some venues. Use TRACE only for local debugging, and redact TRACE logs before sharing them. :::: ## 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`.
Shown in full with attribution under the source's licence. Licence: LGPL-3.0
This summary was written by Stratmill's research agent from the original; it is not a copy of the source.