New Hope PRO

cTrader FIX API vs Open API: Credentials and Key Differences

October 15, 2026

A requirements diagram separates current market data and trading from broader account and historical information, then checks broker permission and application compatibility.

cTrader FIX API provides live quotes and trading operations. Open API also provides account information and historical requests, within its supported methods and limits. Balance, margin and historical market data are not available through cTrader FIX API.

Start with the data and actions your strategy needs. For a Pepperstone or other cTrader account, confirm the broker, account type and connection route before reusing settings. Then check which functions your software supports for that exact configuration.

FIX credentials: open cTrader settings, then FIX API. Price and trade connections use separate credentials; check the broker-specific symbol IDs.
Open API access: accounts permission is read-only; trading permission allows permitted trading operations. Match the connection to demo or live.
New Hope PRO setup: confirm the supported route and required functions for your broker account before choosing a package.

Check my account compatibility with New Hope PRO

In the form, tell us your broker, server, demo or live account status and intended instruments. Do not send passwords or API keys.

Get free access to New Hope PRO lessons

Explore the setup process in the New Hope PRO training simulator before buying the software. The lessons are free. The team will review your access request and email you an invitation.

Already have access? Open the setup lesson · Explore New Hope PRO

Three layers must fit together

A working setup needs agreement between three layers: the platform's API, the broker account's permissions and the application's implementation. A capability documented by the platform may still require a suitable account and explicit support in the software.

Think of compatibility as an intersection. If the API provides an operation but the application never implements it, the operation is not available through that application. If the application can send it but the account is not permitted to use it, the request may fail. A successful login proves only part of the chain.

Write requirements in plain language first: receive current prices, place the intended order type, see whether it filled, inspect existing positions, obtain the account information needed by the strategy, and recover safely after a disconnect.

What cTrader FIX API is designed to do

FIX is a financial messaging protocol. cTrader's FIX interface focuses on receiving live market data and performing trading operations. Its documented limitations include the absence of historical market-data requests and account information such as current balance, leverage and margin. See the official introduction and limitations.

Those boundaries are useful design information. They tell an evaluator which questions require another supported source or a different integration approach. They are not a reason to fill missing values with assumptions.

For example, a system that needs current account balance to decide whether an action is permitted must explain where that information comes from. Receiving current quotes does not answer the balance question. Receiving an execution message does not automatically produce a complete historical account statement.

What Open API adds to the comparison

cTrader Open API supports custom applications connected to the cTrader backend. Its documentation describes real-time market data, trading operations and access to past, current and pending operations. It also describes application authentication and request limits. See Open API's official overview.

For a purchaser, the practical question is not whether this sounds broader. It is whether the chosen software exposes the required functions, handles their responses and documents the relevant limitations. Broader platform scope does not prove a particular product is a better match.

Requirement	cTrader FIX API	cTrader Open API
Current market data	Within documented scope	Within documented scope
Trading operations	Within documented FIX scope	Within documented Open API scope
Historical market data	Not provided by this FIX interface	Check supported historical requests and limits
Balance and margin information	Not provided by this FIX interface	Check the required account-data fields
Application compatibility	Must be confirmed separately	Must be confirmed separately

Worked example: a narrow execution requirement

Consider a hypothetical application that receives an external signal and needs current quotes, order submission and execution responses for one authorized account. It does not use historical candles in the connection itself.

A first review could map those requirements to the documented FIX scope. That is only the beginning. The reviewer still needs the exact order types, supported instrument identifiers, account rules and recovery behavior. The phrase “FIX supported” does not answer whether every intended action is implemented.

Create a short acceptance test: connect to the appropriate test environment, identify the instrument, obtain a current quote, submit an authorized test instruction and reconcile its final state. Record observed responses rather than treating the connection light as the test result. Do not perform live trades merely to complete a software checklist.

Worked example: a dashboard and trading workflow

Now imagine a different application that needs the current account state, a list of past operations and current positions before it permits a new action. This has a broader information requirement than the previous example.

The review should identify each required field and its authoritative source. “Balance” needs a clear timestamp and account identity. “History” needs a defined period and a way to detect incomplete results. “Current positions” needs reconciliation after reconnecting. A screen that displays plausible values is not enough if their source and freshness are unknown.

Open API may be relevant to this broader requirement, or an application may use a documented combination of supported sources. That is an architectural possibility, not a claim about how New Hope PRO is built. Ask the vendor to describe the actual route used by your configuration.

Four connection errors to rule out before changing software

A connection can succeed at one layer and fail at the next. Use the symptom to choose the first check, then keep the actual error response. These are checks of cTrader's documented connection model, not a claim that every New Hope PRO connection uses the same interface.

What you observe	First check	Why it matters
FIX prices arrive, but trading requests fail	Confirm that the application uses the trade connection for trading requests.	cTrader provides separate price and trade credentials. They are not interchangeable. See the official FIX credential guide.
The subscribed instrument is not the one you expected	Recheck the FIX symbol ID in the current broker account.	A symbol ID can differ between brokers. Copying a profile to another broker does not verify the new instrument mapping.
Open API displays the account but cannot trade	Check the permission granted to the application.	The accounts scope is read-only; trading scope permits trading operations, subject to the account permissions. Grant only the access needed by the application.
An Open API demo account cannot authenticate on the chosen connection	Match the account to the demo or live endpoint.	Demo and live environments are separate. A working live connection cannot be used to authenticate a demo account.

Resolve one mismatch at a time and repeat the failed check in an appropriate test environment. Keep passwords, tokens and secret values out of screenshots. If the documented settings match but the problem persists, send support the non-secret account environment, interface, software version and exact error. Repeatedly retrying an uncertain order without checking its status can create a different problem.

Why a protocol choice is not a speed result

An API's design and an observed execution outcome are different kinds of evidence. Network path, application handling, request content, broker processing and market conditions can all matter to the measured sequence. A protocol label alone does not tell you what your account will experience.

Define the measurement endpoints first. Are you measuring receipt of a quote, submission of a request, acknowledgement, or a completed fill? Comparing unlike intervals can produce an impressive-looking number that answers no useful question.

Use the execution audit to organize those timestamps. If you are reviewing historical inputs, the tick-data guide explains another distinction: access to a current stream does not establish the quality or availability of historical test data.

To compare quote delivery separately from order execution, use the fast-feed evaluation checklist. Record the price side, clock basis and receipt times before interpreting a lead between two streams.

A practical checklist before selecting the route

List required data fields and actions without naming a protocol.
Match each requirement to the platform's current documentation.
Confirm broker, account type, environment and permissions.
Ask the software provider which functions are implemented in the specific build.
Define a test for order status and position reconciliation.
Document disconnect, uncertain-response and credential-rotation procedures.
Keep a dated record of the approved combination.

If orders are rejected, preserve the actual response and use the diagnostic guide. Do not switch connection types randomly while also changing strategy parameters; that makes it difficult to establish what fixed the problem.

How this relates to New Hope PRO

New Hope PRO 1.5.24 supports MetaTrader 4/5, FIX API and cTrader connectivity. That confirmed product scope does not establish which cTrader API is used internally by each connection, or promise that every broker/account combination is suitable.

The accompanying video opens at a New Hope PRO discussion of order settings and FIX-related context. It is product orientation, not a demonstration of the entire cTrader API comparison. For actual setup, follow the New Hope PRO connection guide and request confirmation of the exact route.

The full $5,000 package includes broker information, prepared broker/instrument settings and manager assistance. The one-time $500 month is for personal evaluation of the robot and instructions only, with no broker list, prepared settings or help configuring profitable trading. Review the product options before choosing. Technical compatibility does not guarantee trading results.

A compatibility brief for your New Hope PRO setup

Before choosing a package or renting a server, prepare one short brief. This gives the team a concrete configuration to review instead of the broad question “Does cTrader work?”

Broker and exact account type; demo or live.
Instruments and the actions you need: quotes, opening orders, closing positions and account information.
The proposed connection route, or a note that it still needs confirmation.
New Hope PRO version, Windows environment and any VPS already in use.
What you have tested, the outcome and any error message, with secrets removed.

Ask which functions are supported by that specific combination and what must be verified before live use. The product's list of platforms does not replace this account-level check.

Next step: review the New Hope PRO packages and connection options, then contact the New Hope team with your compatibility brief. For the server decision, compare MetaTrader virtual hosting and a Windows VPS: a hosted terminal and a Windows desktop are different environments.

Once you have checked the connection requirements, use the one-month New Hope PRO evaluation plan to decide what to test, which records to keep and whether the evaluation or full package fits your preparation. Free Workspace learning is available before either software purchase.