> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.paradex.trade/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.paradex.trade/_mcp/server.

# 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](https://github.com/tradeparadex/starknet-signing-cpp/tree/a4978dbba8dfe2db42b38d07287fb0abf5f66627?tab=readme-ov-file)

## 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](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](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.

> **Tip**
>
> Reference: [Orders API Documentation](/api/prod/orders/batch)

## 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.

> **Tip**
>
> Reference: [WebSocket API Documentation](/ws/general-information)

## 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.

> **Tip**
>
> Reference: [Rate Limits Documentation](/api/general-information/rate-limits/api)

## 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.

> **Tip**
>
> Reference: [WebSocket Rate Limits](/ws/general-information/rate-limits)

## 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.