Tradovate API 408 Request Timeout (1 Connection)
A 408 on Tradovate isn't a slow-network timeout. It means you've blown past the number of connections your account is allowed to hold at once, and a standard account only gets one.
You've got a bot talking to the Tradovate API, orders are flowing, and then out of nowhere the calls start coming back 408 Request Timeout. On most servers a 408 means “you were too slow, I gave up waiting.” On Tradovate it means something completely different, and once you know what it's really telling you, the fix takes about thirty seconds. A 408 here is Tradovate's way of saying you've blown past the number of connections your account is allowed to hold at once. A standard account gets exactly one concurrent connection. If the Trader web app, a REST session, and your automation are all fighting for that single slot, the extras get bounced with a 408. Close whatever else is logged in as you, make sure only one thing connects at a time, and the error clears. A managed bridge like PickMyTrade sidesteps the whole problem by holding one clean connection for you.
Quick Checklist for the 408 Request Timeout Error
- Close the Trader UI. If you've got Tradovate Trader open in a browser tab, the desktop app, or on your phone, it's holding your one connection, shut it down before your bot runs.
- Kill duplicate instances. A crashed or restarted script that never logged out leaves a ghost session. Confirm only one copy of your app is authenticating.
- One login at a time. Don't fire two logins for the same account in parallel, stagger startup so the old session drops before the new one connects.
- Renew, don't re-auth. Use
/auth/renewAccessTokento extend your session instead of logging in fresh every cycle, which piles on connection churn. - Need both? Get the second slot. To watch Trader and run a bot at once, you need the two-connection add-on, one slot can't do both.
- Keep the socket alive. Send a heartbeat every 2.5 seconds so an idle WebSocket doesn't get cut and force a messy reconnect.
What "408 Request Timeout" Means on Tradovate
In plain HTTP, 408 Request Timeout is the server telling a client it waited too long for the request to arrive and closed the door. Tradovate reuses that status code for its own purpose. On this API, a 408 is what you get when you exceed the maximum number of concurrent connections tied to your user. It's not about network latency or a slow request body, it's a capacity signal. The platform is saying, “too many of you are logged in as you right now.”
That reframing matters, because if you chase a 408 like a normal timeout, bumping request timeouts, retrying harder, blaming your VPS, you'll get nowhere. The number to look at isn't your latency. It's how many things are authenticated against your account at the exact moment the error fires.
You Get One Connection. That's the Whole Story.
Here's the rule that explains almost every 408: a standard Tradovate user gets a single established connection to the API per account. That one slot is shared by everything that authenticates as you, the Trader web app, the Trader desktop app, the mobile app, a REST session, and the market-data WebSocket your bot opens. They don't each get their own line. They all reach for the same one.
Tradovate spells out the consequence directly: logging on to Tradovate Trader ends your REST API and WebSocket session, and the reverse is true too. So if your bot is happily streaming quotes and you pop open Trader in a browser tab to eyeball a fill, one of them has to lose. The one that gets bumped starts throwing 408s. Flip it around, your bot reconnects while Trader is open, and now Trader is the one that drops. It feels random until you realize there was only ever room for one.
Top Causes of the Tradovate 408
1. The Trader App Is Open While Your Bot Runs
This is the everyday culprit. You leave Tradovate Trader open on a second monitor, a phone, or a forgotten browser tab, then start your automation. The bot connects, takes the slot, and Trader, or the bot, depending on timing, starts getting 408s. Anything that shows a live Tradovate session counts, including the mobile app running quietly in the background.
2. A Restart or Crash Left a Ghost Session
Your script dies, restarts, and logs in again, but the previous session never cleanly logged out on the server side. For a short window you're holding two sessions against a one-slot account, and the new connection collects 408s until the old one times out. Auto-restart loops make this worse, because they can stack login after login before any of them expire.
3. The Same API Key Running From Two Places
Cloud deployments are notorious for this. An auto-scaling group spins up a second container, or you leave a copy running on your laptop and another on a VPS, and both authenticate with the same credentials. Each new login fights the others for the single connection, and the 408s never settle down because nothing ever backs off.
4. A Tight Reconnect Loop
When a socket drops, a naive client reconnects immediately, and if it's dropping for another reason (a missed heartbeat, say), you end up hammering login. That flood of connect attempts both trips the connection ceiling and racks up request traffic, so the 408s can get tangled up with rate-limit penalties on top.
How to Fix the 408 Request Timeout: Step-by-Step
Free up your one connection
Close everything else that logs in as you. Sign out of Tradovate Trader in every browser tab, quit the desktop app, and close the mobile app fully (not just background it). Give it a few seconds so the session actually releases on the server. This single step clears the majority of 408s, because most of the time the “extra” connection is just Trader sitting open.
Hunt down duplicate sessions
Check for a stale copy of your own app. If your bot crashed and relaunched, an old process may still be authenticated. On a server, list running processes and confirm exactly one instance is live. In a scaled cloud setup, make sure only a single node ever authenticates for a given account, pin the connection to one worker instead of letting every replica log in.
Stagger your logins and renew, don't re-auth
Design your startup so a new session waits for the old one to drop before connecting. And instead of calling the login endpoint every cycle, which spins up fresh connection churn, extend the session you already have. Send a POST to /auth/renewAccessToken with your still-valid token to get a new expiry without opening a brand-new session. Fewer logins means fewer chances to trip the connection ceiling.
If you truly need two things at once, add the second slot
Some workflows genuinely need Trader open and a bot running, you want eyes on the ladder while automation manages exits. One connection can't do that. Tradovate offers a paid add-on that raises your ceiling to two concurrent connections; watching Trader plus one API app then fits comfortably. You enable it from your Tradovate account's subscription or add-on settings, the exact menu label has shifted over the years, so open your account management area and look for the connection or subscription add-on that mentions concurrent or dual connections, and confirm it's active before you rely on it.
One caveat worth burning into memory: even with two slots, a sloppy restart that briefly holds three sessions still throws 408. Two is the ceiling on that plan, not an invitation to open connections freely. The discipline of “one clean login at a time” still applies, you just have a little more headroom.
Keep the Connection Alive So It Doesn't Drop
Half the 408 pain comes from connections dropping and reconnecting badly. Keep the socket healthy and you stop generating the churn that trips the limit in the first place.
- Heartbeat every 2.5 seconds. The Tradovate WebSocket expects a heartbeat frame, an empty
[]payload, at least every 2.5 seconds, or the server closes it for inactivity. A server that's actively streaming market data won't send its own heartbeats, so it's on you to keep the pulse going. - Don't lean on
setIntervalin a browser. Background tabs throttle timers, which silently starves your heartbeat and drops the connection. Timestamp each message you receive and send a heartbeat once 2,500 ms have passed since the last one. - Use unique request IDs. Reusing the same integer ID on concurrent requests can confuse the socket and drop it.
- Reconnect before ~24 hours. Long-lived sockets get cut around the 24-hour mark, so plan a graceful reconnect rather than waiting for the server to sever it mid-session.
Troubleshooting Table
| Symptom | Likely Cause | Fix |
|---|---|---|
| 408 the moment the bot connects | Trader UI (web, desktop, or mobile) is already holding the slot | Sign out of Trader everywhere, then connect the bot |
| 408 right after a crash or restart | Ghost session from the previous run hasn't timed out | Wait for the stale session to expire; ensure one instance logs in |
| 408 that never settles | Same API key authenticating from two machines or replicas | Pin the connection to a single node/process |
| 408 even with the add-on | Three+ sessions briefly held (e.g., overlapping restart) | Stagger logins; still keep it to one login at a time |
| Socket drops, then 408 on reconnect | Missed heartbeats causing a reconnect flood | Send an empty [] heartbeat every 2.5 s; back off retries |
| 429, not 408 | Too many requests too fast (rate limit) | Throttle request rate, different problem, different fix |
Where PickMyTrade Fits
Juggling a single connection slot by hand is fragile, one stray Trader tab or one messy restart and your automation starts bouncing 408s at the worst possible moment. PickMyTrade sits between TradingView and Tradovate and holds one clean, managed connection so you're never fighting yourself for the slot:
- One managed connection, the bridge keeps a single, stable session to Tradovate, so duplicate logins and ghost sessions don't stack up against your limit.
- Automatic session upkeep, tokens are renewed on schedule and heartbeats keep the socket alive, so it doesn't drop and trigger a reconnect storm.
- No raw connection plumbing, you route TradingView alerts and let the platform handle the connect/authenticate/reconnect cycle you'd otherwise babysit in code.
- Rate-limit-aware routing, requests are paced so you don't trade a 408 for a 429 penalty.
Stop Wrangling API Connections
Start your free trial, connect TradingView to Tradovate without wrangling API connections.
Start Your Free 5-Day TrialFrequently Asked Questions
On the Tradovate API a 408 almost always means you've exceeded the maximum number of concurrent connections for your user. A standard account gets one connection slot, so if the Trader app, a REST session, and your bot all try to hold it at once, the extra sessions start returning 408.
A standard user gets a single established connection to the Tradovate API per account. Logging on to Tradovate Trader ends your REST API and WebSocket session, and vice versa. A paid add-on raises the ceiling to two concurrent connections so you can watch Trader and run an app at the same time.
Yes. On a single-connection account, signing into the Trader web or desktop app takes the one slot and ends your API session. When your bot reconnects, it kicks Trader off. Only one of them can hold the connection at a time unless you have the two-connection add-on.
It gives you a second slot, so watching Trader plus running one API app fits inside the limit. It won't help if your own code opens more than two sessions at once, a duplicate bot instance left running after a restart still pushes you over the ceiling and the 408s return.
Usually a phantom session. A crash or hard restart left an old login active on the server, so when your new instance authenticates you briefly hold one session too many. Wait a minute for the stale session to time out, make sure only one instance logs in, then reconnect.
Send a heartbeat frame, an empty [] payload, every 2.5 seconds, use unique request IDs, avoid firing calls in tight bursts, and reconnect before the roughly 24-hour connection cap. In a browser, don't rely on setInterval for the heartbeat; background tabs throttle it and the socket dies.
No. A 429 means you sent too many requests too fast and hit a rate limit. A 408 on Tradovate points at the concurrent-connection ceiling, too many simultaneous sessions, not too many requests. They have different fixes, so read the status code before you react.
This guide is for educational and informational purposes only and is not financial, investment, or trading advice. Trading futures and other leveraged products carries a substantial risk of loss and is not suitable for every investor. PickMyTrade is an independent third-party automation platform and is not affiliated with, endorsed by, or sponsored by Tradovate, Inc. All related names, logos, and trademarks are the property of their respective owners. Platform features and steps change over time, so always confirm the current process in the official Tradovate platform and documentation before acting.