Centralized crypto exchanges (CEXs) like Binance, Coinbase, Kraken, and others provide market data and trade notification feeds to support real-time trading, analytics, and infrastructure integration. These feeds are broadly categorized into two main types:

Market Data Feeds

These feeds provide pricing and order book information. Common subtypes include:

Order Book Feeds (Level 2 / Depth)

• Real-time updates of the order book (bids and asks).
• Often implemented using WebSocket connections.
• Supports snapshots + incremental updates (delta updates).
• Examples: depth, bookTicker, orderBookUpdate.

Trade Feeds (Ticker Tape)

• Streams of individual executed trades.
• Includes fields like: price, size, trade direction, timestamp.
• Examples: aggTrade, trade.

Candlestick (Kline) Feeds

• Periodic OHLCV (Open/High/Low/Close/Volume) data for charting.
• Useful for technical analysis.
• Comes in intervals (1m, 5m, 1h, etc).

Ticker Statistics

• 24-hour rolling stats (high, low, volume, price change).
• Usually REST + WebSocket options.

Trade Notification / Account Feeds

These feeds notify users of events specific to their accounts.

User Data Stream (Private WebSocket)

• Requires authentication (API keys + session tokens).
• Common events:
  • Order updates: submitted, partially filled, filled, canceled, rejected.
  • Balance updates.
  • Margin/liquidation alerts (on margin/futures platforms).
• Examples: executionReport, outboundAccountPosition.

Transport Mechanisms

• WebSocket: Primary real-time transport for most exchanges.
• REST API: Used for snapshots, historical data, and authentication.
• Some exchanges (like Coinbase or Binance) also offer:
  • FIX Protocol for institutions.
  • GRPC or HTTP/2 in more modern setups.
  • Kafka / Webhook integrations in enterprise APIs.

Market Nuances in CEXs

• Not all exchanges offer the same granularity or latency.
• Rate limits and throttling apply—especially on public APIs.
• Some data (like full order books or low-latency feeds) may be paywalled or require institutional access.
• Eventual consistency issues can occur—e.g., order book updates may arrive out of order or delayed.

Technical Details

Here’s a technical breakdown of how market data and trade/account notifications are exposed via APIs and protocols on CEX crypto exchanges. I’ll cover the common patterns and some specifics from leading exchanges like Binance, Coinbase, and Kraken.

---

1. Protocols and Transport Mechanisms

WebSocket (WS)

• The dominant protocol for real-time data streaming.
• Bi-directional, low-latency, ideal for:
  • Market depth
  • Trade ticks
  • Private order notifications

REST APIs

• Used for:
  • Initial data snapshots (order books, balances)
  • Placing/canceling orders
  • Historical data
• Stateless, request/response pattern.
• Often rate-limited heavily vs WebSocket.

FIX (Financial Information eXchange)

• Supported by some CEXs (e.g., Coinbase Prime, Kraken Pro) for professional/institutional users.
• Primarily for order entry and trade notification, not market data.
• Low latency, session-based, strict message encoding.

Other (less common)

• Webhooks (for private notifications—rare in CEXs, more common in wallets or SaaS).
• gRPC / HTTP/2 (emerging in some institutional APIs).
• Kafka / raw TCP in co-location or enterprise settings (e.g., Binance's institutional suite).

---

2. Market Data APIs

Order Book Snapshots (REST)

• URI: GET /api/v3/depth
• Params: symbol=BTCUSDT&limit=1000
• Returns:
  • "bids" and "asks" arrays with price/quantity
  • Non-incremental (full snapshot)

Order Book Stream (WebSocket)

• WS stream: wss://stream.binance.com:9443/ws/btcusdt@depth
• Also: @depth20@100ms for throttled updates
• Update schema includes:
  • u: final update ID
  • bids, asks: changed price levels only
• Consumers must sync snapshot + deltas using update IDs to maintain consistency.

Aggregated Trades

• Stream: @aggTrade (Binance)
• Fields:
  • p: price
  • q: quantity
  • T: trade time
  • m: is buyer maker?

Candlesticks (OHLC)

• Stream: @kline_1m (Binance)
• Contains:
  • Open, high, low, close, volume, number of trades
  • Period open/close timestamps

---

3. Private Notification Streams

User Data Streams (WebSocket)

• Requires REST request to get a temporary WS listen key:
  • POST /api/v3/userDataStream
  • Then: wss://stream.binance.com:9443/ws/<listenKey>
• Events:
  • executionReport: order lifecycle events (NEW, FILLED, CANCELED)
  • outboundAccountPosition: balance updates
  • balanceUpdate: fee deductions or manual balance changes

Order Notification (FIX)

• Order events use messages like ExecutionReport, OrderCancelReject
• Lower latency and better for deterministic processing
• Requires pre-approved sessions, credentials, and often VPN or dedicated links

---

4. Security and Rate Limits

• REST APIs require HMAC-SHA256 signed headers (using API secret + nonce/timestamp)
• WebSocket private feeds often require a temporary auth token or listen key
• Rate limits vary:
  • Binance: 1200 weight per minute (with different weights per endpoint)
  • Coinbase Pro: ~10 requests/sec per profile
  • Kraken: call cost model using “weights” per endpoint

---

5. Example Payloads

Binance ExecutionReport (WebSocket)

{
    "e": "executionReport",
    "E": 123456789,
    "s": "BTCUSDT",
    "S": "BUY",
    "o": "LIMIT",
    "f": "GTC",
    "q": "1.0",
    "p": "50000.0",
    "X": "FILLED",
    "i": 12345,
    "l": "1.0",
    "z": "1.0",
    "L": "50000.0",
    "n": "0.001",
    "N": "BNB"
}

Coinbase Trade Message (WebSocket)

{
    "type": "match",
    "trade_id": 10,
    "maker_order_id": "ac928c66-ca53-498f-9c13-a110027a60e8",
    "taker_order_id": "132fb6ae-456b-4654-b4e0-d681ac05cea1",
    "side": "buy",
    "size": "0.012",
    "price": "4000.00",
    "product_id": "ETH-USD",
    "sequence": 50,
    "time": "2022-01-01T00:00:00.000Z"
}