This tutorial describes some of the common best practices that should be followed by CRM systems/client areas integrated with the WebServices API.
Successful WebServices API integration is only possible if your CRM/client area supports the following use cases (for a refresher on key terms, refer to the definition of our domain model).
As such, you should prioritise the implementation of these use cases in your integration process. We recommend conducting extensive testing of your implementation as the functionality listed above is crucial for any effective CRM/client area linked to the cTrader backend.
The WebServices API exposes several endpoints that you can consume to display various analytics to your traders.
Here are just some examples of the data you can show in your client area.
a. Total realised P&L for all positions closed during a specific period.
b. The asset classes, symbol categories, and/or symbols that the trader has frequently placed new orders for during the past month.
c. The total volume of all positions currently opened by the trader.
d. The balance and equity of all Copy sub-accounts created by the trader.
e. The winning/losing trade ratio for a chosen period.
The API calls you can use to attain the relevant data are listed below.
Note that the WebServices API does not allow for receiving real-time events, meaning that you would need to send separate requests each time you want to refresh the statistics shown in your CRM system/client area. In this case, make sure that such requests are sent at reasonable intervals (e.g., once when a trader opens the analytics page and then every minute until the trader leaves the page). We reserve the right to restrict access to the WebServices API if you send requests with excessive frequency (e.g., every second).
If you want to react to new data arriving in real time, consider additionally integrating with the Reporting API.
To correctly handle the creation and linkage of all major server entities in the cTrader backend, you should send the following API calls in the order given below.
In our domain model, users are higher-order entities to which new traders are linked; as such, creating new users first is the recommended flow for any integration.
When someone new registers inside your CRM, the need to create a new user in the cTrader backend depends based on whether your CRM/client area is designed to accept registrants from different platforms.
This decision-making process can be explained via the following flow chart.
If your CRM/client area only takes new traders from cTrader, there is no need to determine the platform that a new registrant comes from. As a result, you can request the creation of a new cTrader user each time someone new completes the signup process in your CRM.
In contrast, if your CRM/client area can take new registrants from several different platforms, there may be no need to create a new user in the cTrader backend. As a result, you would need to design and implement a custom mechanism for determining the platform that a new registrant wants to use. If this mechanism identifies cTrader as the preferred platform, you would need to create a new user entity.
As an example, your CRM/client area may show an interactable platform selector menu to all new registrants. You would need to create a new user only after cTrader is selected in this menu and the registrant confirms their choice.
It is essential to differentiate between the following types of withdrawals requests.
Withdrawal requests received by a backoffice manager can be handled and processed according to your internal business logic. However, when such a request is is received, it is imperative for its results to be reflected in the cTrader backend. To achieve this goal, you should send API call 4.7 with "type": "WITHDRAW" and "preciseAmount": {withdrawalAmount}in the request body.
Sending API call 4.7 request (and receiving a successful response) has to occur earlier than processing the withdrawal request in your system (e.g., by returning the withdrawn funds to the trader via bank transfer). This is needed to avoid a case where a trader can place new orders using the money that they have technically already withdrawn.