AI Guide Map
Exchange Integration Pattern Library
Reusable blueprints for building cryptocurrency exchange integrations. Pick the pattern that matches the workflow, then open an implementation guide when Binance, Bybit, or another exchange needs exact SDK calls, request fields, event topics, or error handling.
Available now: historical backfill plus live streams, exchange state management, order intent execution, and focused exchange request-shape guides.
Default Scope
- Audience: developers and AI coding agents building cryptocurrency exchange integrations
- Runtime: Node.js LTS with TypeScript recommended
- Packages: selected exchange SDK for the selected venue
- Execution: DEMO, TESTNET, and LIVE remain disabled by default until the selected EXECUTION_MODE value is explicitly configured and all required gates pass.
Starter Patterns
| Workflow | Use Case | Guidance |
|---|---|---|
| Historical Backfill with Live WebSocket Streams | Backfill historical data and keep in sync using live streams | Use an exchange-specific candle implementation when exact SDK fields are needed; Binance and Bybit examples are tested overlays, not the only valid candle venues. |
| Exchange State Management | Track and react to account state changes, such as position updates (new/increased/reduced/closed). React to position changes, placing/amending/cancelling TP/SL/DCA orders after fills. | Open the exchange implementation for SDK clients, topics, fields, and rejection codes. |
| Order Intent Chasing with Exchange APIs & WebSockets | Approved order intent follows the price with a maker order to fill as soon as possible. | Keep signal generation and risk approval outside the execution adapter. |
| Stop Loss using Conditional Algo Orders with Binance USD-M APIs & WebSockets | Exact Binance USD-M conditional order fields | Use alongside Exchange State Management for account-state workflows. |
Core patterns
Reusable exchange-neutral lifecycles. Start here before choosing exchange-specific request fields.
Execution adapters
Use after a strategy, operator, or risk layer has already approved an order intent.
Exchange implementations
Exchange-specific pages apply a core pattern to concrete SDK methods, request fields, topics, product names, and error handling.
Binance
2 resourcesBybit
2 resourcesExchange request shapes
Focused exchange semantics for request builders and validation rules.
Agent artifacts
Machine-readable entry points for generators and coding agents.
Implementation Steps
Follow these in order; use the linked artifacts only where they clarify the current step.
Combining Patterns
Most real systems use more than one pattern. A strategy can consume a historical backfill plus live stream pipeline, emit approved intents, and pass them to an execution adapter. A position manager can track exchange state and react to position changes to manage TP/SL/DCA order mechanics.
- Choose one owner for account state, order ownership, and private-event ingestion.
- Use implementation guides for exchange-specific SDK details before writing request builders.
- Keep the write-capable EXECUTION_MODE values DEMO, TESTNET, and LIVE disabled by default until credentials, configuration, exchange rules, venue routing, and local validation have been reviewed.
- Trace the lifecycle chain for each pattern before connecting it to another pattern.
- Add fixtures for cross-boundary handoffs such as data-ready -> signal, signal -> approved intent, and approved intent -> execution adapter.
Use Patterns Safely
- Choose a pattern by lifecycle: historical backfill plus live streams, exchange state management, execution, or exact request shape.
- Read the matching exchange implementation before coding SDK calls, request fields, event topics, product modes, or error handling.
- Keep account-state ownership, Custom Order ID ownership, and private-event ingestion explicit when combining modules.
- Fixture or replay coverage must match each lifecycle claim; unsupported behavior should be named as unsupported.
- Keep the write-capable EXECUTION_MODE values DEMO, TESTNET, and LIVE disabled by default until credentials, config, exchange rules, venue routing, and local validation have been reviewed.