v1.5.0 - 2025-08-02

✨ Added - Enhanced Order Tracking

Optional User ID Field for Order Tracking

• Added user_id field to all order types for enhanced tracking and analytics:
  • REST Endpoints: All limit orders (POST /limit), market orders (POST /market), combo orders (POST /combo), and RFQ orders
  • WebSocket Events: Trade events now include user_id field in data payload
  • Field Type: Optional string with maximum 36 characters
  • Use Cases: Custom order labeling, client-side tracking, analytics categorization, portfolio grouping

Migration Example:

// Before (existing functionality continues to work)
const limitOrder = {
  instrument_name: 'BTC_USDC-29AUG25-106000-C',
  type: 'good_til_cancelled',
  contracts: 1.5,
  direction: 'buy',
  price: 1000.5,
  // ... other required fields
};

// After (optional user_id field available)
const limitOrder = {
  instrument_name: 'BTC_USDC-29AUG25-106000-C',
  type: 'good_til_cancelled',
  contracts: 1.5,
  direction: 'buy',
  price: 1000.5,
  user_id: 'portfolio_a_trade_001', // New optional field
  // ... other required fields
};

Benefits:

• Custom tracking: Label orders with your own identifiers for easier management
• Portfolio organization: Group orders by strategy, client, or trading session
• Analytics enhancement: Track performance metrics across custom categories
• Backwards compatible: Existing code continues to work without changes

🔧 Changed - RFQ Validation and Rate Limiting

Breaking Change: RFQ Opposite Direction Requirement

• RFQ responses now require opposite directions between taker requests and maker limit orders
• Traditional market making: Takers request one direction, makers provide liquidity in the opposite direction
• Enhanced validation: System validates direction compatibility before accepting RFQ responses

Before:

// Previously allowed (incorrect market making)
const rfqResponse = {
  fills: [
    [
      {
        instrument_name: 'BTC_USDC-29AUG25-106000-C',
        contracts: 1.5,
        direction: 'buy',
      }, // Taker request
      {
        instrument_name: 'BTC_USDC-29AUG25-106000-C',
        contracts: 1.5,
        direction: 'buy', // Same direction - previously allowed but incorrect
        price: 2500.0,
        // ... other limit order fields
      },
    ],
  ],
};

After:

// Now required (correct market making)
const rfqResponse = {
  fills: [
    [
      {
        instrument_name: 'BTC_USDC-29AUG25-106000-C',
        contracts: 1.5,
        direction: 'buy',
      }, // Taker request
      {
        instrument_name: 'BTC_USDC-29AUG25-106000-C',
        contracts: 1.5,
        direction: 'sell', // Opposite direction - now required
        price: 2500.0,
        // ... other limit order fields
      },
    ],
  ],
};

Benefits:

• Correct market making: Ensures proper liquidity provision patterns
• Reduced errors: Prevents mismatched trading pairs that could lead to unintended positions
• Market integrity: Aligns with traditional finance market making principles

WebSocket Rate Limiting Scope Change

• Rate limiting changed from per-API-key to per-session for WebSocket connections
• Independent limits: Each WebSocket connection now has its own 15 requests/minute limit
• Same endpoints affected: get_ob_state_by_instruments and get_ob_state_by_market

Before:

// All connections using the same API key shared a single rate limit
// If you had 3 WebSocket connections with the same API key,
// they collectively shared 15 requests/minute

After:

// Each WebSocket connection gets its own independent rate limit
// 3 WebSocket connections = 3 × 15 = 45 total requests/minute

Benefits:

• Better scalability: Multiple connections per API key don't interfere with each other
• Fairness: Each connection gets full rate limit allocation
• Simplified management: Rate limits tied to connection lifecycle rather than API key usage