Understanding Tradovate API Rate Limits

Tradovate imposes rate limits on their API to protect their infrastructure and ensure fair access across all integrations. As a MimikTrader user, understanding the broker response helps you diagnose an unusual request delay. MimikTrader handles a typed penalty response only within the lifetime of the affected request; it does not use a shared transport limiter or priority queue.

Tradovate's Rate Limits

Tradovate enforces two tiers of rate limiting on API requests:

• Hourly limit: 5,000 requests per hour per OAuth application. This is a rolling window, not a fixed clock-hour boundary. It covers all API calls including order placement, account queries, position checks, and token refreshes.
• Per-minute limit: 80 requests per minute per OAuth application. This is the more restrictive limit in practice and the one most likely to be encountered during high-frequency trading activity.

These limits apply to the OAuth application (MimikTrader's registered application with Tradovate), not to individual user accounts. This means all MimikTrader users share the same limit pool for a given OAuth application credential.

How MimikTrader Handles Penalty Responses

Request-Scoped Handling

A Tradovate WebSocket response can contain a typed p-ticket string and a typed p-time delay. MimikTrader recognizes that pair for the affected request and waits once for the broker-provided delay. There is no token bucket, shared wait queue, or priority queue.

The original request context remains the cancellation authority. If it is cancelled before the delay completes, the resend is suppressed. If the delay completes first, MimikTrader sends the request once more with the ticket. A penalty response does not create an additional retry.

OAuth Application Pool

To handle scaling across many users and accounts, MimikTrader maintains a pool of OAuth application credentials. Instead of routing all API traffic through a single application, the platform distributes requests across multiple registered OAuth apps. Each app has its own independent rate limit allocation, effectively multiplying the available capacity.

This pooling happens transparently — you do not need to configure anything. MimikTrader's backend automatically assigns your accounts to an appropriate OAuth application and balances the load across the pool.

Request Optimization

MimikTrader minimizes unnecessary API calls through several optimizations:

• WebSocket connections for real-time trade detection, which do not count against REST API rate limits.
• Batching related requests where the Tradovate API supports it.
• Caching account metadata and instrument definitions that do not change frequently.
• Proactive token refresh before expiration to avoid redundant authentication requests.

What Is a P-Ticket?

Tradovate can return p-ticket and p-time as JSON response fields instead of a normal result. The ticket identifies the penalty response and the time value supplies the wait before the one permitted reaction.

MimikTrader validates the typed fields, retains the same response handler, and uses a new request ID for the single resend. The request is not placed in a shared queue, and caller cancellation can end a pending wait before that resend is selected.

When You Might Hit Rate Limits

Under normal trading activity — even with 10 or more follower accounts — the rate limits are not a concern. Each trade copy generates a small number of API calls (the order placement and any bracket orders), well within the 80-per-minute limit.

Situations where rate limits could become a factor:

• Very high-frequency trading: If the leader account is scalping with dozens of round trips per minute across multiple instruments, the volume of API calls can approach the limit, especially with many followers.
• Mass flatten events: If multiple accounts hit their risk limits simultaneously and all need to be flattened at the same time, the burst of close orders can spike the request count.
• Connection recovery: After a network outage, MimikTrader may need to re-sync account states and positions, which generates additional API calls.

Best Practices

• For most users, no action is needed. If an action is delayed or rejected, review its request result and the connection state.
• If you trade very frequently, consider grouping follower accounts across separate copy groups with different leader accounts. This spreads the API call load more evenly.
• Avoid unnecessary reconnections. Disconnecting and reconnecting accounts repeatedly consumes API calls for token refresh and account synchronization.
• If you are running more than 20 follower accounts, contact support so we can ensure your accounts are distributed optimally across our OAuth application pool.