Rate Limits & Best Practices

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

Rate Limit Overview

To prevent things like DDoS attacks, Tradovate limits request rates and imposes time penalties when certain thresholds are triggered. There are request limits on the hour, minute, and second intervals. Generally, the limits are high enough not to hit them during normal operations.

Rate Limit Types

Standard Rate Limits

REST API Endpoints:

General Endpoints:     * 1,000 requests/second 
                       * 5000 requests/minute
                       * 5000 requests/hour
Authentication:        10 requests/minute
Reporting:             200 requests/minute

Rate Limit Response Format

When limits are exceeded, you may receive different types of responses depending on the endpoint type and severity:

Standard 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:

• Cannot be resolved programmatically from third-party applications
• Users must wait 1 hour before sending another request
• No p-ticket is provided with 429 responses (unlike penalty tickets)
• Inform users about the 1-hour wait requirement

Penalty Ticket Response

For “novel” operations (infrequently called endpoints like authentication, account signup, password changes), the system may return a penalty ticket in the response body of a successful HTTP response (200 OK). When you receive a penalty ticket, the request was not handled and the server has imposed a time penalty.

Important: Penalty tickets are returned in successful HTTP responses (200 OK), not as 429 errors. Always check the response body for p-ticket fields, even when the HTTP status indicates success.

Handling Penalty Tickets (P-Tickets)

Novel operations that are known to be called infrequently have further constraints placed upon them. These operations include requesting an access token, signing up for an account, changing a password, or changing contact information. These operations are not intended for frequent use.

If a client reaches one of these limits, a special time-penalty response will be issued. This response is a JSON object with the fields "p-ticket" and "p-time". If you receive this response, it means that the request was not handled and the server imposed a time penalty on that request.

Common endpoints that return penalty tickets:

• /auth/accesstokenrequest - Authentication requests
• Account signup endpoints
• Password change endpoints
• Contact information update endpoints
• Other infrequently used operations

Important: Penalty tickets are returned in successful HTTP responses (200 OK), not as error status codes. You must check the response body for penalty ticket fields, even when the HTTP status indicates success.

Penalty Ticket Response Format

When a penalty ticket is issued, the response body contains:

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

Response Fields:

• 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

Handling Penalty 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

Note: One scenario where p-captcha: true can occur is upon too many authentication requests with sent bad data (incorrect username or password).

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
};

Key Implementation Notes

Important Points:

• The request was not handled - When you receive a penalty ticket, the server did not process your request
• Penalty tickets are returned in successful HTTP responses (200 OK), not error responses
• Always check the response body for p-ticket fields, even when the HTTP status is 200
• The client can retry the call in p-time seconds
• Include p-ticket as an additional parameter in the request body’s JSON when retrying
• If p-captcha is true, the operation cannot be tried again from a third party application - users should be alerted to try again in an hour

reCAPTCHA Rate Limiting (p-captcha)

In addition to the p-ticket and p-time fields, there is a field called p-captcha. When this field is marked true, it means the operation that failed cannot be tried again from a third party application and users should be alerted that they should try the operation again in an hour.

reCAPTCHA Response Format

When reCAPTCHA is required, the penalty ticket response includes:

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

Important: When p-captcha is true, the operation cannot be tried again from a third party application. This typically occurs with “novel” endpoints like /auth/accesstokenrequest that are intended to be used infrequently or through the official Trader application.

Common Scenario: One time this can occur is upon too many authentication requests with sent bad data (incorrect username or password).

Handling reCAPTCHA Lockouts

Critical: When you receive a penalty ticket with p-captcha: true:

1. Stop immediately: Do not attempt to retry the request programmatically
2. Inform users: Notify users that they must wait 1 hour before retrying
3. Do not retry: Cannot be resolved from third-party applications
4. Wait full duration: Users should wait the full p-time period (typically 1 hour)

Best Practices for reCAPTCHA Lockouts

Critical Guidelines:

• Check p-captcha first: Always check this field before attempting retries
• Immediate Cessation: Stop all retry attempts when p-captcha is true
• User Communication: Clearly inform users about the 1-hour wait requirement
• Monitor Failed Attempts: Track authentication failures to prevent lockouts
• Valid Credentials Only: Only retry with confirmed correct credentials

Critical Warnings

Best Practices Summary

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 */}