Skip to content

Rate Limits & API Usage

This page defines the throughput constraints and operational usage rules that client code should follow when using the Nubra Python SDK. Respecting these limits is important for stable trading execution, reliable market-data access, and compliant production behavior.

What This Page Covers

This page covers limits and usage guidance for:

  • trading APIs
  • historical data access
  • live WebSocket market-data subscriptions

LLM guidance

Generated code should centralize throttling instead of making uncontrolled per-widget or per-function requests. Use streaming where appropriate, and avoid bursty polling patterns for live workflows.

Published Limits

API Category Limit Scope
Trading APIs in PROD 10 operations per second per IP, standard unregistered algo guidance
Trading APIs in UAT 100 operations per second testing and simulation guidance
Historical Data usage 60 requests per minute analytical access
Live WebSocket streams weight-based per session

Quick Interpretation

Use these limits as the first implementation baseline:

  • PROD trading should stay within 10 ops/sec unless you have approved higher throughput.
  • UAT trading allows higher throughput for testing.
  • Historical data should be rate-limited and batched thoughtfully.
  • Live market data should prefer WebSocket subscriptions instead of aggressive polling.

Trading API Limits

The core trading APIs such as place, modify, and cancel are optimized for low-latency execution and are subject to operational and exchange-facing limits.

  • Standard production guidance for unregistered algorithms is 10 order operations per second
  • UAT allows 100 operations per second
  • Limits are enforced per IP address
  • Higher production throughput requires formal approval

Historical Data Limits

Historical data access over REST is limited to:

  • 60 requests per minute

This limit is intended for research, analytics, and backtesting workloads. If your application needs repeated time-series access, cache results locally and avoid re-fetching the same windows unnecessarily.

Live Market Data Limits

Live market-data subscriptions over WebSocket are governed by a weight-based session model.

  • Each stream type consumes a defined number of weight points
  • The allowed total weight is enforced per session
  • Requests that exceed the remaining session weight are rejected
  • Unsubscribing from streams frees capacity for new subscriptions

Use WebSocket subscriptions for live dashboards and active monitoring instead of repeated REST polling.

For detailed stream weights and session limits, see Subscription Limits.

Algo Registration For Higher Limits

If your production strategy needs throughput above the standard unregistered trading guidance, the algorithm must be formally registered through Nubra.

To discuss algo registration and approved higher limits, contact:

  • support@nubra.io

Implementation Patterns

Use these patterns when building clients with the SDK:

  • centralize throttling in one helper or request manager
  • batch reads where the SDK supports grouped or filtered requests
  • prefer subscriptions over repeated live polling
  • unsubscribe from unused streams to recover WebSocket weight
  • separate UAT and PROD behavior in your runtime configuration

Common Failure Patterns

Avoid these patterns:

  • one-request-per-widget polling for dashboards
  • treating UAT throughput as safe production throughput
  • opening more WebSocket subscriptions than the current session weight allows
  • retry loops that resend requests immediately without backoff

Important Rules

  • UAT and PROD trading limits are different. Do not treat UAT throughput as the production-safe baseline.
  • Production trading guidance for unregistered algorithms is 10 operations per second per IP address.
  • Historical data usage is limited to 60 requests per minute.
  • Live market-data subscriptions are governed by a session-level weight model, not a simple request count.
  • Subscription requests that exceed available weight are rejected until existing streams are removed.
  • Use WebSocket for live monitoring workflows instead of aggressive REST polling.
  • If your strategy needs higher production throughput, complete algo registration before scaling request rates.

The most relevant follow-up pages are:

  1. Historical Market Data
  2. Realtime Data
  3. Place Order
  4. Modify Order
  5. Cancel Order
NEO Assistant