Historical-data pacing limits how quickly an app can request bars. Repeating the same request at once can make the problem worse. Identify the request pattern and apply the current rule for its bar size and data type.
Educational software guidance. Trading involves risk. Read the financial and information disclaimers.
Step by step
- 1 In a TWS chart, open Edit → Chart Parameters. Note Time period and What to show. For an API query, save the actual contract, bar size, dates and time from the app log; chart settings do not control the app request.
- 2 Check whether the client is repeating the same requests or opening many charts at once.
- 3 Pause duplicate queries and ask the client to queue requests at a supported rate.
- 4 Reduce history you do not need and reuse saved data where suitable. To review a recorded API log, use Help → Troubleshooting → Diagnostics → API Logs. An empty list means there is no saved log to check.
- 5 Test a small request sequence and watch for another pacing message.
A practical example
An app opens twenty charts and asks for the same old bars each time you switch tabs. That may waste requests. A better request plan reuses data already fetched and spaces out the new work. To test the cause, use one chart and one small range. If that works while the full burst fails, preserve the two logs for the app provider. Do not keep repeating the burst just to see whether the next try passes.
Screen reference




Mistake to avoid
Common questions
Do all bar sizes use the same limits?
No. Read the rule for the requested data, especially small bars.
Should I retry continuously until it works?
No. A retry loop can keep the app over its limit.