Integration overview
Integration architecture
What are the parts of the integration
The broker's integration consists of two independent parts: data integration based on a server-to-server architecture and trading integration based on a client-server architecture.
Data and trading integration endpoints can be located at different base URLs. You can also implement different authentication methods for each integration.
Why data integration is needed
The TradingView website can only receive data from the TradingView server. Indicators are counted on this server, as well as server alerts, etc. Data integration is required for the market data to be first received by the TradingView server, and then transferred to the client side. For FOREX and CRYPTO, the data needs to be connected in any case, as it is not linked to the particular exchange and is always different. For CFD it is possible to use existing data via /mapping if the CFD is mapped to a specific exchange stock.
In what cases it is possible not to integrate data
Market data can come to the TradingView server from another source, for example, directly from the exchange. There is no need for market data integration in this case, and the broker needs to implement the /mapping endpoint to solve the symbol names matching issue between the TradingView and broker symbols.
Is it possible to restrict access to market data
You can restrict access to market data or hide symbols for some users. For example, restrictions can be made depending on the users' login, location, or subscription plan. To have such restrictions, you need to implement the /permissions endpoint. Refer to the Permissions article for more information.
Features of the implementation of some endpoints
Processed once at login: /config, /accounts, /instruments, /ordersHistory, /permissions.
The rest of the requests are sent either on a regular basis or are the result of user actions. In the first case, their frequency is set using Pulling intervals in the /config. In the second case, it happens in the Trading section.
In some cases, the listed endpoints may not be implemented.
- /mapping is not required if you work exclusively on your own symbols.
- /executions can be disabled through the config, but in this case, transactions will not be displayed on the chart.
- /positions can be disabled through the config, not used for Crypto Spot trading.
- /balances can be disabled, used for Crypto Spot only.
- /depth can be disabled if you are not going to support DOM display.
- /permissions and /groups are not required if you do not restrict access to certain data for certain user groups (for example, depending on the subscription plan or location).
Streaming endpoints in trading integration
Streaming endpoints are an alternative to regular endpoints. Regular endpoints are usual REST API requests — the client makes a request to the server, initiating an HTTP connection. The server closes the connection after providing a response.
Using streaming endpoints may be feasible in the following use cases:
- When the broker server has requests frequency limit resulting in 429 response codes, or when traffic is billed on a per request basis
- When concurrent connection from several tabs is required, streaming endpoints allow to decreas the requests number unlike regular REST endpoints where this number is multiplied by the number of open tabs
- When reducing amount of data transmission is required. Streaming endpoints messages are only expected where there is an update. In regular endpoints, a full snapshot of data is expected
The full list of corresponding streaming endpoints is provided in the Endpoint requirements article.
It is possible to use only a subset of streaming endpoints. Streaming endpoints configuration is done on the TradingView side upon request.
Trading integration issues
How trading integration works
The trading integration uses a client-server architecture: requests from the user's browser are sent directly to the broker's server. The TradingView server is not involved in this data exchange. An exception is a request to /permissions. It is sent from the TradingView server to give the user access to the data.
Requests from the client browser require a configured CORS policy on the broker side.
Environment types
There are three environment types used in the integration development and support. Each environment type contains real market data and has its own URL.
- The production environment is available to end users.
- The staging environment is used for testing.
- The local environment is used on the TradingView developers' computers.
They connect to the broker's staging environment from the
localhost:6285address.
Note that TradingView and the broker both implement the production and staging environments on their sides.
Connection to your staging environment must always be accessible to TradingView team and our internal services for testing purposes.
The table below describes six pairs of environment connections between TradingView and the broker.
| TradingView environment | Broker environment | Description |
|---|---|---|
| Localhost | Staging | An environment that TradingView developers use for troubleshooting. |
| Staging | Staging | An environment that the broker uses during integration development in the TradingView sandbox. |
| Production | Staging | An environment that TradingView and the broker use to test any changes the broker made after release to the TradingView production environment. Used to ensure that changes do not affect the broker production environment. |
| Localhost | Production | An environment that TradingView developers use for troubleshooting. |
| Staging | Production | A pre-release environment that TradingView developers use for testing features implemented by the broker. At this stage, TradingView performs the final testing of the broker’s production API and deploys the TradingView client applications. |
| Production | Production | A live production environment that is ready for users. |
The TradingView website in a staging or production environment can only be connected to one broker environment at a time. After the TradingView team completes the configuration, you will be informed how to switch between environments through the browser console.
Sandbox
The sandbox is a fully functional copy of the TradingView website at beta-rest.xstaging.tv. During the integration development in the sandbox, you need to work on the UX and ensure the trading functionality works as expected.
Get access to sandbox
To get access to the sandbox, follow the steps below:
Ensure that the following two conditions are met:
Provide the TradingView team with the following information:
Your IP addresses. The team will whitelist them in TradingView to grant access to the sandbox.
Client identifier, authorization URI, client secret (for Code Flow only), and token endpoint URI (for Code Flow only) if you implement the OAuth2Bearer type of authorization. Refer to the Authentication section for more information.
SVG icons for the trading panel and login dialog. Refer to the table below for icons requirements.
Placement Requirements Trading panel One icon for both dark and light themes.
Size: 56×56px.
Border radius: 0px. The TradingView team will change border radius depending on the icon location.
Format type: SVG.
Color scheme: no requirements.
The TradingView team will provide you with further instructions.
Localization support
Usually, the integration of a specific broker is aimed at an audience using their national language. However, English language support is required for all requests coming from the main locale of the TradingView application.
The user's locale can be determined through the locale query
parameter, which is present in every request coming from the client to
the broker's server.
CORS policy
Test servers and website versions in different languages are located on
*.tradingview.com subdomains. For example, the German version of the
site is located at de.tradingview.com. TradingView can send a request
from any of these addresses.
Therefore, you must include an Access-Control-Allow-Origin response
header with the specific subdomain that sent the request in each
endpoint for each response code.
During sandbox testing, it is also necessary to allow requests from
*.xstaging.tv.
In addition, in the broker staging environment it is necessary to allow
requests from the localhost:6285. This address is used on developers'
computers.
Why use HTTPS
Please avoid using HTTP instead of HTTPS. Our website is prohibited from
accessing anything through the insecure HTTP protocol by
Content-Security-Policy. HSTS disallows access to anything over the
insecure HTTP protocol. Moreover, HSTS is exposed for 730 days and
applies to all subdomains. For us to be able to make an HTTP request to
your staging even from our staging, we will have to:
- Turn off HSTS in production.
- Wait for two years.
Data integration issues
Data requirements
All the data which is displayed at TradingView has to meet the following standards:
- Real-time data obtained from the /streaming endpoint must match the historical data, obtained from the /history API. The allowed count of mismatched bars (candles) must not exceed 5% for frequently traded symbols, otherwise, integration into TradingView is not possible.
- Historical data should look healthy. It must not contain unreasonable price gaps, 1 min and D-resolution history holes, and incorrect prices.
- Chart data must match between TradingView and data provider platforms.
The user sees bars built from streaming ticks on the chart. The /streaming data is replaced by the data from /history sometime after the user reloads the chart. The data from /streaming and /history must be the same. Data mismatch can lead to a false alert triggering for the user, which is unacceptable. The data in /history shouldn't change.
To make sure you meet this requirement, record your streaming trades in a few minutes.
{
"id": "BTCUSDT",
"p": 33405.5,
"t": 1624797120,
"f": "t",
"s": 0.092
},
{
"id": "BTCUSDT",
"p": 33417.5,
"t": 1624797179,
"f": "t",
"s": 0.057
}
We can build 1-minute bar from this data:
{
"s": "ok",
"t": [1624797120],
"o": [33405.5],
"h": [33417.5],
"l": [33405.5],
"c": [33417.5],
"v": [0.149]
}
Here, o is the price of the first deal, c is the price of the last
deal, and v is the sum of sizes (s).
Then we request
/history:
/history?symbol=BTCUSD&resolution=1&from=1624797120&to=1624797179. The
resulting bar must match the bar built from
/streaming.
Endpoints requirements
Data integration requires the implementation of three endpoints:
- /symbol_info — a list of symbols and a set of rules for them; the endpoint is requested once an hour.
- /history — full data history for each symbol gap on 1-minute bars (candles); in some cases, the history of daily bars may be required.
- /streaming — a permanent HTTP connection, a stream of messages on completed deals; data feed should provide trades and quotes. In some cases, daily bars may be required.
- /groups - a list of possible symbol groups. Used to differentiate instrument types, to restrict access to market data, or to hide symbols for some users.
If your data is not public, you can add authorization via the /authorize endpoint. Two authentication options are supported: PasswordBearer and ServerOAuth2Bearer.
Requests frequency
Below is the information about frequency of the data integration endpoints requests:
/symbol_info is requested once every 30 minutes in order to keep symbol specification as relevant as possible.
/streaming keeps a constant connection. It is only re-requested if the previous connection gets broken. TradingView establishes a total of 4 connections: 2 for TradingView production environment, 1 for TradingView stable environment, and 1 for TradingView staging environment.
/history endpoint is requested every 2 hours between 0 and 11 AM UTC and between 4 and 11 PM UTC. /history is requested for every symbol which lacks historical data for more than three days. By default, requests are split by one full day, or maximum of 1440 of 1-minute bars. An example in cron syntax is below.
0 0-11/2,16-23/2 * * *
/history will be requested to retrieve lost data whenever any real-time data issues occur.
The requested data time interval can cover more than 1440 of 1-minute bars while manually requesting /history. Please reach out to TradingView team If there are any limitations for the maximum number of bars in the response.
Types of environments
We strongly recommend using two environments in the integration process: staging and production. Each environment must have a separate URL.
First, the broker's staging connects to the staging of TradingView. Initial automated testing is done here, and then manual tests are performed after.
The broker staging API should provide real data.
When the acceptance tests are successful, the broker deploys own code to the production environment. The final testing of the broker's production API and the deployment of the TradingView client applications are to be performed here.
All changes on the broker side go through the following steps after the deployment to the TradingView production:
- Changes are made in the broker's staging environment.
- They are then tested on the TradingView side.
- The broker transfers the changes to the production once confirmed by TradingView.
Both environments on the TradingView side are switched to the production URL once the broker's API is deployed to production.
Thus, there will be 4 client applications running on the TradingView side all the time, which will interact with the broker's production API: two in the staging and two in the production.
Each of these applications will maintain at least one persistent HTTP connection to the /streaming endpoint and make regular requests to the /symbol_info, /history. The data is requested only by our API client applications running on the servers. The end-user browser never makes requests to these endpoints.
TradingView client applications use a separate set of credentials per environment by default (if authorized).
Therefore, the broker should provide at least two independent sets of credentials to its production API: one is for clients in the TradingView production, one is for clients in the staging, testing and development.
If the number of simultaneous connections is limited to one connection per account, the broker needs to provide the required number of credentials sets:
- two for client applications in the staging,
- two for client applications in the production,
- two for development and testing.