cTrader API Rate Limits: Plan Requests Before Connecting
cTrader API rate limits put a ceiling on request frequency. They are not a guarantee of response speed or a target your application must reach. Identify the relevant request category and connection before evaluating a polling routine or accepting a developer’s claim that an integration can run without constraints.
This guide provides a request-inventory worksheet and questions for reviewing software. It supplies no trading code, recommends no request rate and makes no performance claim. Use the current official documentation and the application’s actual behavior together.
The documented cTrader API rate limits
The official Open API introduction publishes separate per-connection limits for historical and non-historical requests. Consult its Rate limiting section for the current numerical ceilings. These are separate categories. Check the current reference when reviewing a configuration, because an old tutorial is not a substitute for the active documentation.
Record the category and connection for each request in your inventory. Do not combine both numbers into one generic allowance. Ask the developer how it identifies historical requests and how it accounts for all work sharing a connection. A dashboard’s refresh interval may not describe every request the application sends.
Inventory requests by purpose
Start with a list of functions the application performs: reading account information, retrieving history or carrying out another documented task. Ask which request each function uses and how often it runs. Keep the function name and technical message identifier in separate columns.
If a function creates several requests, record that relationship explicitly. A single user action can involve more than the visible button suggests. This is a question for the developer to explain, not an assumption that every action has the same network cost.
Separate categories in the worksheet
Give historical and non-historical requests separate totals for each connection. Retain the observation period and measurement method. An average calculated over a long period may not explain a short burst. Ask which records show the pattern that matters to the documented per-second limit.
This article does not prescribe a method for operating close to the ceiling. A limit describes a constraint, while the application design needs its own documented margins and failure behavior. Request the reasoning behind the proposed configuration rather than selecting the largest published number as a default.
Check a request inventory against the source
Take the developer’s inventory and select a documented function. Identify its request category and the connection carrying it. Compare those entries with the official rate-limiting section. The purpose is to establish whether the explanation uses the same categories and scope as the documentation.
If the inventory lacks a time window or measurement method, mark that question unanswered. A number without its scope is insufficient for the comparison. Ask the developer to supply the missing context rather than extrapolating a performance claim from an isolated count. This is a document review, not a measured test of a real application.
Ask about shared connections
Identify which components share each connection and who owns its request scheduling. Ask whether a background task, interface refresh or another component adds requests to the same stream. A review limited to the most visible feature can leave part of the inventory unanswered.
Keep the answer scoped to the actual application version and environment. A general capability description does not establish how a particular deployment distributes work. If the developer proposes a configuration change, record the change and its purpose without assuming it resolves every request-count question.
A worksheet for cTrader API rate limits
| Field | Record |
|---|---|
| Function | The user-facing or background task involved |
| Request | The documented message or operation identifier |
| Category | Historical or non-historical, with supporting reference |
| Connection | The stream that carries the request |
| Observation | Count, time window and method used |
| Failure behavior | The documented response-handling process |
Add a source link and an unresolved column. A category should not be guessed from a friendly feature name. If the documentation and developer explanation differ, retain the discrepancy and ask for clarification. Do not complete the table with an invented message identifier.
Errors need their own evidence
cTrader’s official error-handling guide describes error responses and order-related error events with code and description fields. It explains that unsupported messages and connection problems are among possible error contexts. Read the actual response rather than assigning every failure to the request limit.
Ask the developer how the application captures those fields and makes them available for troubleshooting. Remove sensitive information before sharing records. A generic “failed” message can leave the underlying reason unresolved; the relevant documented response may support a more precise question.
Ask the developer to document retries
Ask whether the application retries a request, when it does so and how the retry enters the request count. Obtain a documented explanation for the actual request type. Keep the retry question unresolved until the developer supplies the relevant behavior and its documentation.
For any account-changing action, ask how the software reconciles an uncertain response before deciding on another attempt. This guide provides no retry algorithm or trading instruction. The purpose is to identify the developer’s supported process and the evidence it uses.
Connectivity and data freshness are different checks
A connected indicator does not establish the age or completeness of every displayed record. Ask how the application identifies the time of its last successful update and how it presents a failed refresh. Keep those questions distinct from whether the connection itself exists.
Likewise, a published request ceiling does not establish how fast a particular response will arrive. Avoid treating the number as a latency benchmark. A performance claim needs its own measurement method, environment and scope. This article reports no measured response times.
Development observations have limits
If a developer demonstrates request handling in a demo environment, retain the environment label, software version and observation period. Record which functions were active during the exercise. A test that excludes background work cannot automatically establish its later behavior.
Keep the result scoped to what was observed. It does not prove a future live account’s execution, costs or financial outcomes. A technical demonstration can clarify request handling without becoming a certification of the whole application or its trading strategy.
Questions for a software review
Ask for the request inventory, category mapping, connection ownership and error-response process. Request a clear description of what happens when the observed workload differs from the planned one. Keep the answers with their date and version reference.
If the supplier answers only with the published maximum, the application-specific question remains open. Official documentation establishes the constraint; the developer must explain the implementation. A logo or successful connection screenshot cannot replace that explanation.
Frequently asked questions
Are historical requests covered by the same number?
The official introduction lists separate ceilings for historical and non-historical requests. Record both categories rather than applying one blended allowance. Check the current reference before reviewing a particular deployment.
Does an error prove the rate limit was exceeded?
No. Inspect the actual error code and description using the official error documentation. Preserve unknowns when the available record does not establish a cause. A failed action can require a different explanation.
Do higher request counts mean a better application?
This guide makes no such ranking. cTrader API rate limits describe constraints, while application quality requires a scoped review of behavior and evidence. A request count alone does not establish usability, suitability or financial performance.
Editorial scope and disclosure
By Best Forex Brokers Editorial. This guide uses official documentation and an original document-review worksheet. We claim no measured API performance or software certification. Our editorial methodology explains evidence standards.
Best Forex Brokers may earn commissions from qualifying referral links elsewhere on this site. This guide contains no broker referral recommendation; platform references are informational.
This is not financial advice or investment advice. Leveraged forex and CFDs can cause substantial losses. Product availability, account rules and legal protections depend on your jurisdiction and contracting entity.
