cTrader API Demo: Separate Testing From Live Accounts
A cTrader API demo setup needs an explicit environment check. A connected application is not automatically a practice application. Establish which endpoint and account the software uses before interpreting a response or allowing any account action. Keep demo observations labelled throughout the exercise.
This guide provides a configuration and evidence worksheet. It does not connect your account, supply trading code or recommend moving software into a live environment. Its purpose is to help you ask precise questions about the boundary between development and real account activity.
What the official documentation establishes
cTrader’s Open API introduction says the service supports demo and live accounts and recommends demo accounts for development and testing. The API can exchange information and support permitted trading operations. Those capabilities make account context important: an API connection is not inherently read-only or simulated.
The official endpoint guide describes fully separate demo and live environments. It states that a demo account cannot be used through a live endpoint, or the reverse. An application operating across both environments needs separate connections. Verify the actual configuration rather than inferring it from the application’s name.
Identify the cTrader API demo endpoint
Ask the developer to identify the environment selected by the application. Request a non-sensitive configuration record showing that selection. A label on a dashboard can help navigation, but the underlying connection configuration is the relevant evidence for the endpoint question.
Use the current endpoint documentation for host and protocol details. Do not copy a live endpoint into a practice configuration merely because a tutorial uses it. This article intentionally provides no executable connection sample. A worksheet can establish the intended environment without placing any account instruction.
Account identity is a separate check
Next, identify which account the application has authorization to access. Keep the account environment and endpoint environment as separate entries. Ask how the software confirms that the selected account matches the intended practice setup.
If several accounts are available, request an explanation of the selection process. Avoid assuming that the first account in a list is the intended one. Save the non-sensitive account context with each exercise. Remove account secrets from screenshots or shared troubleshooting records.
Write a narrow test objective
A useful objective concerns one observable behavior, such as displaying the selected environment or reading a documented account record. State the expected result before the exercise. Keep the objective distinct from a trading strategy or a claim about future returns.
Ask the developer which actions the exercise may perform and which permissions it requires. If the answer includes account changes, request their exact scope and environment. A vague phrase such as “just testing” is not a sufficient description of software behavior.
A cTrader API demo worksheet
| Check | Evidence |
|---|---|
| Endpoint | The selected environment and current official reference |
| Account | The intended practice account and selection process |
| Permissions | The documented access scope granted to the application |
| Objective | The single behavior the exercise intends to observe |
| Result | The actual response and relevant environment label |
| Limit | What remains unverified about a live deployment |
Retain a date and software version with the worksheet. A result from an older version may not describe a later configuration. Mark unresolved cells clearly. Do not turn an unanswered permission question into a yes merely because the application connected successfully.
Separate connectivity from functional evidence
A connection message answers a narrow question about connectivity. It does not establish that the application selects the intended account, interprets every response correctly or reconciles state after an interruption. Ask for evidence of the particular behavior under review.
For example, a practice exercise might observe a documented response and compare it with the expected record. Label that result as an observation in the demo environment. Avoid presenting it as proof of live execution quality, current costs or account suitability.
Keep simulated outcomes in their own record
If an exercise produces simulated positions or transactions, record the environment in the file name and the description. Keep those records separate from live account evidence. A selected demo result should not become an advertisement for a developer’s financial performance.
This guide provides no threshold of simulated profit for proceeding to live software. A development observation can establish a specific technical behavior while leaving market outcomes unresolved. The same worksheet should state both the observed behavior and its limits.
Review error handling without assuming a cause
Ask where the application records a rejected request, lost connection or unexpected response. Obtain the relevant documented process from the developer. A blank dashboard alone may not explain what happened to the underlying request.
When investigating an issue, retain the non-sensitive timestamp, environment and response identifier. Separate the expected behavior from the observed record. Do not assign a cause from a screen impression when the supporting response has not been inspected.
A fictional development example
Imagine a developer proposing an exercise that reads a practice account’s identifying context. The worksheet names the demo endpoint, intended account and expected response. After the exercise, the observer records what appeared and links the applicable documentation. No trade is part of this fictional task.
That observation does not establish every later feature of the application. A later feature that submits instructions needs its own scoped review. Keep the original note unchanged, and create a separate record for the new question. This prevents a small successful check from acquiring a much broader meaning.
Review changes as changes
If the endpoint, account selection or permission scope changes, record the change date and its purpose. Ask the developer which previous observations still apply. Do not overwrite an older demo record so that it appears to describe a later live configuration.
Similarly, a software update deserves a clear version reference. Ask whether it changes the behaviors your worksheet covers. The purpose is traceability, not an assertion that every update is unsafe. A dated configuration record lets you compare evidence without guessing which version produced it.
Questions for the developer and broker
Ask the developer to explain environment selection, account selection, permission scope and the location of relevant responses. Ask the broker which account configuration and product documents apply. Keep each answer attached to the party responsible for that part of the system.
If an answer concerns a different environment, request clarification. A general statement that the API supports demo accounts does not establish the application’s actual selection. The official capability and the observed configuration are related but distinct findings.
Frequently asked questions
Can a live endpoint use a demo account?
The official endpoint guide says the environments are separate and the account must match the endpoint. Review the current guide and the application’s actual configuration. Do not infer the environment from a friendly dashboard label alone.
Does using the API mean an application only reads data?
No such assumption follows from the service name. The introduction describes capabilities that include trading operations. Obtain the application’s actual permission scope and behavior rather than equating an API connection with read-only access.
Does a successful demo exercise prove live results?
No. State the technical observation and its environment precisely. A cTrader API demo exercise does not guarantee live execution, financial outcomes or contractual conditions. This guide recommends no move to real funds.
Editorial scope and disclosure
By Best Forex Brokers Editorial. This guide uses official cTrader documentation and a fictional development example. We claim no account connection 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.
