cTrader Open API: Accounts vs Trading Scope

A cTrader Open API app that only needs account data should request the accounts scope: cTrader documents it as view-only, with trading operations impossible. The trading scope also grants access to permitted trading operations, so treat it as a separate decision rather than the default.

That distinction is easy to miss when an integration screen says “connect account.” Connection is not one permission. Scope, the specific accounts you authorise, and the rights on each trading account are separate parts of the boundary.

What do cTrader's two Open API scopes allow?#

An OAuth scope defines what an application is allowed to request through the API. cTrader Open API documents two values: accounts provides access to account information and statistics but cannot perform trading operations; trading adds all trading operations permitted for the account. cTrader's authentication guide defines those scope names and their effects.

A portfolio display or reporting connector has no obvious reason to receive order authority. A tool that must place or manage orders may need trading, but the scope itself does not decide what action is sensible or supervise the integration.

Scope is not the same as account selection#

The authorization flow also asks the user to permit access to one or more accounts linked to their cTID. cTrader says accounts created later are not automatically authorised; the user must go through the grant flow again to add them. That account selection is distinct from the requested scope. The Open API guide describes both steps.

There is another boundary: account-side access rights. The Open API model lists rights such as FULL_ACCESS, CLOSE_ONLY, NO_TRADING and NO_LOGIN. Those describe what the trader's account permits; an OAuth scope does not turn a restricted account into one with broader trading rights. See cTrader's access-rights model.

Before granting access, check three things independently:

1. Scope: Does the app request accounts or trading, and does its stated purpose require that level?
2. Account selection: Which linked account or accounts will be visible to the app?
3. Account rights: What operations does the broker or account itself permit?

An app can be legitimate and still request more access than a particular task needs. Read its explanation of data storage and processing as well as its feature list; cTrader explicitly asks app providers to make those requirements clear during authorisation.

A read-only-first connection checklist#

Use a staged review instead of treating a successful login as proof that the integration is safe.

1. Write down the task. For a dashboard that displays account statistics, define the required output. Do not add order actions “just in case.”
2. Inspect the requested scope before approval. If a read-only task asks for trading, pause and ask the provider why that extra authority is necessary. This is a review question, not proof of misconduct.
3. Select only the intended account. Avoid authorising other linked accounts that the integration does not need.
4. Verify the result with an account you control. Start with a demo account when available. Confirm that the app can retrieve the intended information and that no order or position changes occur during a read-only workflow.
5. Review the credentials path. cTrader's documented flow returns an access token and a refresh token. Its guide lists the access token lifetime as 2,628,000 seconds and says the refresh token has no expiry period. Treat both as credentials: do not expose them in a shared log, screenshot, source repository or support message. The authentication documentation describes the token exchange; the IETF OAuth 2.0 Security Best Current Practice and OWASP OAuth guidance explain why least privilege and careful token handling matter across OAuth systems.
6. Know how to remove access. Find the provider's and cTrader's current revocation or disconnect procedure before relying on the integration. Recheck the current account list and app permissions after changing accounts or credentials.

This is a review procedure, not a guarantee that a third-party app handles data securely. OAuth scope limits API authority; it cannot certify the provider's infrastructure, code, data retention or business practices. The IETF's guidance is a general security standard, not evidence that cTrader implements every OAuth recommendation in the same way.

How this differs from AI-agent permissions#

Open API scopes answer a specific technical question about an application's API access. They are not a complete permission design for an AI agent, which may combine platform controls, prompts and order execution. For that broader workflow, see the cTrader AI permission checklist. If you are building automation, the cBot decision-log guide covers how to reconstruct state-changing actions afterward.

realbacktesting is a trading-software studio for cTrader, with an emphasis on results and behavior that traders can inspect. The same habit applies to integrations: verify the requested access in the platform instead of trusting a polished connection screen. Our proof process explains how we make published cBot backtests reproducible in cTrader.

Frequently asked#

Can the accounts scope place an order?#

No. cTrader documents accounts as view-only and says trading operations are impossible under that scope.

Does the trading scope guarantee every order will be accepted?#

No. It permits trading operations allowed by the account and the API; it does not override account-side restrictions or guarantee an order outcome.

Does authorising one account include accounts I open later?#

Not automatically, according to cTrader's authentication guide. The user must grant access to additional accounts through the authorisation flow.

The stubborn takeaway#

A connection button is not a permission review. Check the scope, the account list and the account's own rights before you approve access.