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 number 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 one-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: Repeated violations add a fixed back-off to your p-time before you can retry. The back-off is set per endpoint (shown in the tables below).
• Request counting: Some endpoints count all requests toward the limit, while others only count failed requests. See the “Requests Counted” column in each table.

Rate Limits

User-Level Rate Limits

Endpoint-Level Rate Limits

Authentication Endpoints

User Management Endpoints

Customer Application / Subaccount Endpoints

Trading Permission Endpoints

Account & Risk Management Endpoints

Subscription & Entitlement Endpoints

Admin Alert Endpoints

Workspace Template Endpoints

Contact Info Endpoints

Order 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

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

WebSocket Response

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

Handling 429 Responses

• Wait one 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
• p-message: Description of the specific limit that was exceeded - for example, "Rate limit exceeded: more than 20 requests per hour"

HTTP Response

{
    "p-ticket": "encrypted_ticket_string",
    "p-time": 15,
    "p-captcha": true,
    "p-message": "Rate limit exceeded: more than 20 requests per hour"
}

WebSocket Response

a[{"s":200,"i":"42","d":{"p-ticket":"abc123xyz","p-time":15,"p-message":"Rate limit exceeded: more than 20 requests per hour"}}]

Handling Penalty Tickets (P-Tickets)

For how to recover from a penalty ticket, why retrying early makes the penalty worse, what does and doesn’t clear it, and how to reduce penalty tickets in normal operation, see Penalty Tickets (P-Tickets).

Rate Limits Best Practices

Dos ✅

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 one 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