Tradovate API p-ticket / p-time Time Penalty

When your bot is firing orders into fast futures like ES or NQ, nothing stalls an automated Tradovate strategy quicker than a sudden p-ticket / p-time response. The API quietly stops handling your calls and hands back a “time penalty” instead of a fill. You might also see a bare 429 Too Many Requests, a longer freeze that locks your account for minutes, or a p-captcha object that shuts you out for roughly an hour. Every one of these is Tradovate's rate-limiting doing exactly what it was built to do: throttle clients that send requests too fast.

Here's the reassuring part. The fix is deterministic. Wait the number of seconds the server tells you, then resend the same request with the ticket attached. And if you'd rather not hand-roll that logic at all, a properly paced automation layer like PickMyTrade spaces your order flow so the penalty rarely fires in the first place.

What the “p-ticket / p-time” Time-Penalty Response Means

Tradovate enforces request-rate limits on its REST API. Cross a threshold and the server does not process your request. Instead it returns a small JSON object describing a time penalty. Two fields matter: p-ticket (a one-time token that proves you were penalized) and p-time (the number of seconds you have to wait before you're allowed to try again). Getting this object means your call was rejected, not queued. Nothing happened on the server, and it's on your client to wait and re-submit.

This is deliberately different from a hard failure. The penalty is a “cool down and come back” signal. Once you wait the specified p-time seconds and resend the exact same request with the p-ticket value included, the server accepts it as your sanctioned retry. Alongside this, Tradovate may also return a plain 429 Too Many Requests HTTP status when a limit is hit. Both are symptoms of the same root cause: you sent requests faster than the API allows.

There's a third, more serious variant. If a response contains a p-captcha field, Tradovate's own documentation states that a third-party application can't complete the request and that clients “should be directed to try again in an hour.” This usually shows up after repeated bad-credential logins or aggressive automated retries. Unlike a normal p-time wait of a few seconds, it won't clear by hammering the endpoint.

Top Causes of Tradovate Time Penalties

1. Exceeding the request-rate caps

Tradovate applies limits across per-second, per-minute, and per-hour windows. The caps commonly land around 5,000 requests per hour and about 80 requests per minute, with a short block (often cited at ~20-30 seconds) the first time you cross a limit. Treat these figures as guidance, not gospel. The exact caps can change, so confirm the current numbers in Tradovate's live API docs. The moment you breach a window, the server stops handling requests and issues the time penalty.

2. Rapid reconnections and re-auth loops

Authentication and WebSocket reconnection calls count against your budget. A client that logs in, drops, and re-authenticates in a tight loop can burn through the cap purely on housekeeping, before it ever places an order. Reconnect storms are one of the most common ways to trip the penalty.

3. Excessive order modifications and trailing stops

Every modify, cancel, and replace is a separate request. Strategies that constantly nudge stops, like trailing logic that rewrites the stop price tick by tick across several accounts, generate a torrent of calls. This is a leading cause of penalties for copy-trading and multi-account setups.

4. Repeated bad-credential logins (the p-captcha path)

Sending the wrong username, password, or app credentials over and over doesn't just fail, it escalates. Tradovate treats a flood of failed auth attempts as abuse and can return the p-captcha object, pushing you into the roughly one-hour cool-down rather than a few-second p-time wait.

5. Multi-account fan-out

Mirroring one signal across many Tradovate accounts multiplies your request count by the number of accounts. What feels like “one trade” to you can be dozens of API calls in a burst. Without pacing, a large fleet reaches the hourly cap quickly and every account starts collecting penalties.

How to Fix Tradovate Time Penalties: Step-by-Step

Satisfying a p-ticket / p-time penalty

This is the core fix, and it's the pattern Tradovate documents directly:

• Detect the penalty. After each request, check the response body for p-ticket and p-time (and watch for a 429 status). If they're present, the request was rejected.
• Read p-time. This is your wait, in seconds. Don't retry before it elapses. An early retry just earns another penalty.
• Wait the full duration. Sleep for p-time seconds (multiply by 1,000 for milliseconds if your timer expects them).
• Resend the original request, with the ticket. Send the exact same endpoint and payload you sent before, but add the returned ticket value as a "p-ticket" field in the body.

In JavaScript, the official example looks like this:

// You received: { "p-ticket": pTicket, "p-time": pTime }
setTimeout(async () => {
  const okResponse = await fetch(URL + '/order/placeOrder', {
    method: 'POST',
    body: JSON.stringify({
      accountSpec: yourUserName,
      accountId: yourAcctId,
      action: 'Buy',
      symbol: 'MYMM1',
      orderQty: 1,
      orderType: 'Market',
      isAutomated: true,
      'p-ticket': pTicket     // attach the ticket to the retry
    })
  })
}, 1000 * pTime)        // wait p-time seconds first

The key details: keep the original payload identical, attach p-ticket, and only fire after p-time has fully elapsed.

Handling a p-captcha response

A p-captcha field isn't a short wait, it's a stop sign:

• Halt automated retries immediately. Continuing to call the endpoint keeps the block in place and can extend it.
• Verify your credentials. Confirm the username, password, and app/API credentials are correct so the next attempt actually succeeds.
• Wait about an hour, per Tradovate's guidance, before trying again.
• Re-authenticate once, cleanly, after the cool-down. Don't resume a retry loop.

Clearing a severe or persistent p-ticket

If short p-time waits keep repeating, or your API access looks reduced or blocked for an extended period, you've moved past a single-call penalty into a structural rate problem. Fix the rate, not the symptom:

• Throttle at the source. Add a token-bucket or fixed delay so you never approach the per-minute/per-hour caps.
• Prefer WebSockets over REST polling. Subscribe to order and position events instead of repeatedly polling list endpoints.
• Cut modify/cancel churn. Batch or debounce stop updates rather than rewriting them on every tick.
• Stagger reconnections. Add a backoff delay between reconnect attempts so re-auth doesn't spike.
• If access stays blocked, contact Tradovate support to confirm whether a manual reset is required. Some prolonged penalties won't clear on their own.

Troubleshooting Table

Prevent This with PickMyTrade

PickMyTrade routes your TradingView alerts to Tradovate through a managed automation layer, so you never hand-roll retry logic against the raw API:

• Rate-Limit-Safe Routing, spaces order flow so calls stay under Tradovate's per-minute and per-hour caps instead of bursting into a penalty.
• Built-In Retry & Backoff, respects p-time waits and re-submits cleanly, so a transient penalty doesn't drop your trade.
• Reconnect Management, maintains stable sessions with staggered reconnects, avoiding the re-auth storms that trigger p-captcha.
• Multi-Account Pacing, fans a single signal out across accounts without multiplying you straight past the rate limit.