Clarity on WebSocket Request Limits?

API Developers Community Support
1

Hello,

I’m a serial save-and-reload developer, and with the yarn / webpack example from the GitHub, webpack will reload the page with each save, thus re-connecting the Market Data and Tradovate WebSockets. I’m avoiding using REST requests to mitigate p-ticket risk. However, if there is a limit to how often WebSocket connections or requests can be made, I will need to work out a “repeater” architecture for testing and development so that the initial WebSocket connection and authorize requests don’t get inadvertently abused by my clumsy save-and-reload behavior.

The docs and talk a bit about rate limits and p-tickets but don’t give specifics on actual limits. Could you provide any clarification on any hard rate limits for specific endpoints or families of endpoints? Especially if the limits apply differently to WebSocket vs. REST API, e.g.,

  • Initial WebSocket connection = 5/min (within # of simultaneous connection limits)
  • md/ family = 200/min (WebSocket)
  • md/subscribeQuote = 100/min (WebSocket)
  • order/placeorder = 100/min (WebSocket), 10/min (REST API)
  • authorize = 10/min (WebSocket), /auth/accesstokenrequest = 5/min (REST API)
  • etc…

This would be helpful to myself and I’m sure to other developers as well. Many thanks!

2

As long as you implement some kind of retry and support for the time-penalty, it should be OK in production, since you won’t have people constantly refreshing. However, a solution to your dev problem may be in webpack’s devServer configs. Check out this liveReload property and maybe look at hot as well:

3

Great suggestion, thank you!

1 Like