Rate Limits

Understanding and respecting API rate limits ensures reliable, high-performance integrations that scale with your prop firm’s growth.

Rate Limit Overview

The Tradovate API implements a two-tier rate limiting system:

1. User-Level Limits: Applied per user (by user ID) across all endpoints
2. Endpoint-Level Limits: Applied per IP address for specific endpoints

When an endpoint rate limit is exceeded, the user must wait the amount of seconds specified in the p-time before making another request of the same type.

Considerations

• Two-tier rate limiting: Both user-level limits (based on authentication) and endpoint-level limits apply simultaneously. Your requests must respect both.
• Sliding time window: Endpoint limits use a rolling 1-hour window, not a fixed hourly reset.
• Shared IP limits: Endpoint limits are tracked by IP address. If you’re behind a shared IP (corporate network, VPN, shared hosting), you may share limits with other clients.
• Back-off behavior: Repeated violations may extend the required wait time before you can retry.
• Request counting: Some endpoints count all requests toward the limit, while others only count failed requests. See the “Count Success” column in each table.

Rate Limits

User-Level Rate Limits

Endpoint-Level Rate Limits

Authentication Endpoints

User Management Endpoints

Trading Permission Endpoints

Account & Risk Management Endpoints

Subscription & Entitlement Endpoints

Admin Alert Endpoints

Contact Info Endpoints

Rate Limit Responses

User-Level Rate Limits Exceeded (429 Response)

For general rate limit violations, when a limit is reached, the server stops handling requests for a period of time and responds to each new request with a 429 status code.

HTTP Response

1
HTTP/1.1 429 Too Many Requests
2
Content-Length: 0

WebSocket Response

1
[{"s": 429, "i": "request_id"}]

Handling 429 Responses

• Wait 1 hour before sending another request
• Cannot be resolved programmatically from third-party applications

Endpoint-Level Rate Limits Exceeded (Penalty Ticket)

For endpoint-level rate limit violations, the system may return a penalty ticket (p-ticket) returned in successful HTTP responses (200 OK), not as 429 errors. When you receive a penalty ticket, the request was not handled and the server has imposed a time penalty.

• p-ticket: Encrypted penalty token tied to your IP address - must be included as an additional parameter in the request body’s JSON when retrying
• p-time: Penalty duration in seconds - wait this long before retrying the call
• p-captcha: Whether reCAPTCHA verification is required (optional field) - when true, the operation cannot be tried again from a third party application and users should be alerted that they should try the operation again in an hour

HTTP Response

1
{
2
    "p-ticket": "encrypted_ticket_string",
3
    "p-time": 15,
4
    "p-captcha": true
5
}

WebSocket Response

a[{"s":200,"i":"42","d":{"p-ticket":"abc123xyz","p-time":15}}]

Handling Penalty Tickets (P-Tickets)

When you receive a penalty ticket response:

1. Check for p-captcha: If true, stop immediately and inform users to retry in 1 hour (cannot be resolved programmatically from third-party applications)
2. Wait p-time seconds: The client can retry the call in p-time seconds
3. Retry with p-ticket: Include p-ticket as an additional parameter in the request body’s JSON along with your original request data

1
const waitForMs = (ms) => {
2
  return new Promise((resolve) => {
3
    setTimeout(() => {
4
      resolve();
5
    }, ms);
6
  });
7
};
8
9
const handleRetry = async (data, json) => {
10
  const ticket = json['p-ticket'];
11
  const time = json['p-time'];
12
  const captcha = json['p-captcha'];
13
14
  if (captcha) {
15
    console.error('Captcha present, cannot retry auth request via third party application. Please try again in 1 hour.');
16
    return;
17
  }
18
19
  console.log(`Time Penalty present. Retrying operation in ${time}s`);
20
21
  await waitForMs(time * 1000);
22
  
23
  // Retry with original data plus p-ticket
24
  await makeRequest({ ...data, 'p-ticket': ticket });
25
};
26
27
const connect = async (data) => {
28
  const authResponse = await tvPost('/auth/accesstokenrequest', data, false);
29
30
  // Check for penalty ticket in response body
31
  if (authResponse['p-ticket']) {
32
    return await handleRetry(data, authResponse);
33
  }
34
35
  // Process successful response
36
  const { accessToken, expirationTime } = authResponse;
37
  setAccessToken(accessToken, expirationTime);
38
};

Rate Limits Best Practices

Do’s ✅

1. Check response bodies for penalty tickets - Even successful (200 OK) responses may contain p-ticket fields
2. Wait the full p-time duration before retrying penalty ticket requests
3. Include p-ticket in retry requests - Add it to the original request body when retrying
4. Check p-captcha first - Always verify this field before attempting retries
5. Cache responses appropriately to reduce API calls
6. Use batch endpoints when available
7. Prioritize critical requests (orders, risk management)
8. Set up monitoring and alerting for rate limit usage
9. Handle authentication failures gracefully - Track failed attempts to prevent lockouts

Don’ts ❌

1. Don’t ignore penalty tickets - Always check response bodies for p-ticket fields, even on successful responses
2. Don’t retry when p-captcha: true - Stop immediately and inform users to wait 1 hour
3. Don’t retry before waiting p-time seconds - Respect the full penalty duration
4. Don’t forget to include p-ticket - The retry request must include the penalty ticket
5. Don’t make unnecessary API calls - Cache when possible to avoid hitting limits
6. Don’t exceed rate limits consistently - This may result in temporary blocks or reCAPTCHA requirements
7. Don’t implement infinite retry loops - Set maximum retry attempts
8. Don’t skip authentication rate limits - These are stricter and may trigger reCAPTCHA

Requesting Higher Limits

For high-volume integrations, you can request increased rate limits:

Eligibility Criteria

• Established partnership with proven integration
• Proper rate limit handling implemented
• Business justification for higher limits
• Technical review of integration architecture

Support

Need help with rate limiting?

• Partner Success Team - Rate limit increase requests
• Support Center - Troubleshooting guides