Advanced API Trader Best Practices

Order Signing

Native C++ and Rust offer the lowest latency for traders when signing their orders (0.4ms and 0.2ms avg latency). For more information you can visit our github signing library

Cancel By Order ID & Market

There is an optional “market” parameter for cancel by client order id which makes the call significantly faster. https://api.prod.paradex.trade/swagger/index.html#/Orders/orders-cancel-by-client-id

Additionally, if you want to cancel all orders for a market, you can use the cancel all https://api.prod.paradex.trade/swagger/index.html#/Orders/orders-cancel-all and specify market parameter. This endpoint is faster as well.

Batch Order Operations

Efficiency Multiplier: Single batch request = 1 rate limit unit (regardless of 1-50 orders). Use POST /orders/batch and DELETE /orders/batch for 50x efficiency improvement vs individual operations.

Implementation: Batch operations support partial failures - individual order rejections won’t block others. Process response arrays to handle mixed success/failure scenarios. All orders validated by risk engine independently.

Real-Time BBO Feeds

WebSocket Channel: bbo.{market_symbol} provides immediate best bid/offer updates with no artificial throttling. Event-driven updates only when price/size changes - use sequence numbers for message ordering.

Feed Selection: BBO is optimal for price-only strategies and useful when subscribing to snapshot books. For fastest BBO price changes, use BBO feed directly. For fastest full orderbook depth, subscribe to deltas websocket feed instead.

Multi-Market Strategy: Subscribe to BBO feeds for all trading markets simultaneously. Each subscription costs minimal resources and provides real-time pricing for optimal execution decisions.

Rate Optimization

Order Management: POST /orders and DELETE /orders share 800 req/s limit pool. Batch operations consume 1 unit regardless of order count (1-50), providing significant efficiency gains for market makers.

Client ID Optimization: Avoid using client IDs on orders when possible to reduce processing overhead. Only include client IDs when order tracking is essential for your strategy.

Signing Optimization: Order signing is computationally expensive. Pre-sign static order components and only process variable parts (price, size, timestamp) for each new order to reduce latency in high-frequency scenarios.

WebSocket Rate Management

Connection Limits: 20 connections/second, 600 connections/minute per IP. Maintain persistent connections rather than frequent reconnects for optimal performance.

Channel Strategy: Subscribe to essential channels only: bbo.{market}, fills.{market}, positions, order. Avoid unnecessary subscriptions that consume bandwidth.

Message Processing: Drain WebSocket messages quickly to prevent disconnection. Exchange will disconnect if 2000+ messages accumulate unprocessed. Implement fast message handling and avoid blocking operations in message callbacks.

Reconnection Logic: Implement robust reconnection with backoff that respects rate limits (20 connections/second, 600/minute). Queue critical operations during reconnection to avoid data loss.

Node Distribution: Track node_id from authentication responses and avoid connecting to the same node multiple times. Distribute connections across different nodes for better load balancing and redundancy.

Clock Synchronization

Time Sync: Synchronize your system clock with Paradex servers using the Amazon Time Sync Service at time.aws.com. Accurate clock synchronization is critical for order timestamp validation and latency measurements. Ensure your system maintains clock accuracy within milliseconds to avoid order rejections due to timestamp drift.

Latency Monitoring

Timestamp Analysis: Use order response timestamps to monitor network latency for both REST and WebSocket. Track published_at, received_at, created_at, last_updated_at fields to identify bottlenecks in your trading pipeline.

System State Monitoring

Operational Status: Poll GET /v1/system/state to monitor exchange operational state. Handle three status values: ok (fully operational), maintenance (trading unavailable), cancel_only (only cancellations allowed).

Implementation Strategy: Check system state before trading operations and adapt behavior accordingly. During cancel_only periods, halt new order submissions but continue order cancellations to manage risk.