Skip to main content

Authentication

After passing the authentication, regardless of the method of obtaining the access token, all requests to the broker's REST server will use the Authorization: Bearer ACCESS_TOKEN header.

info

The integration authorization must be the only offered action on the authentication page. Placing irrelevant links, promos, sign-up forms, etc., is not allowed as it goes against the TradingView guidelines and affects the overall user experience.

Password Bearer​

In this type of authorization, the user enters their login and password directly on the TradingView website.

Authorization​

  1. A user selects the broker in the Trading Panel, opening a credential entry popup.
  2. After a user submits the form, TradingView sends a POST request with the credentials to the /authorize endpoint.
  3. Your server validates the credentials and, if successful, returns a response containing the token.
  4. TradingView includes this token in the Authorization header for all subsequent requests to your REST server.

Response fields​

  • access_token — the access token used for authorized requests.
  • expiration — token expiration time in Unix Timestamp format, an optional parameter.
info

In the current implementation, the token will not be refreshed, even if the expiration field is provided. For better security, please use the OAuth2 Code flow. By default, placeholders in the authorization popup are login and password. You may provide custom values in English if needed.

OAuth2Bearer​

TradingView's security policy does not allow the same OAuth secrets for all of the six supported connections between the TradingView client and the broker's server. Therefore, all client_id values (and client_secret values in case of using the OAuth2 Code flow authorization option) must be unique. On the TradingView side, all OAuth secrets are kept in a special high-security secret vault. Security audits are performed regularly.

info

OAuth2 Code flow supports token refreshing. The token is refreshed asynchronously and takes some time. Therefore, the broker's server must accept requests with the old access token until requests come with the new token. After that, the old token can be invalidated.

OAuth2 Code flow​

This authorization type is implemented following RFC 6749 section 4.1. The procedures for obtaining an access token and its renewal are performed directly between the TradingView servers and the broker's server, avoiding client-side storage. This flow allows for architectural flexibility: the REST API, OAuth2 authorization page, and access token retrieval endpoints do not need to share the same domain and can be hosted separately.

Authorization​

  1. A user opens the Chart page on the TradingView website, then selects a broker in the Trading Panel.
  2. A login popup appears. The user clicks the Continue button on this popup.
  3. A new browser tab opens at the broker's Authorization URL.
  4. The following query parameters are sent in the GET request:
    • response_type — the value will always be code.
    • client_id — a unique identifier of the client.
    • redirect_uri — Redirection Endpoint. For security reasons, when receiving an authorization request, check this parameter for compliance with the one in the configuration.
    • scope — an optional parameter containing a pre-registered, broker-provided list of space-delimited, case-sensitive strings (per RFC 6749 section 3.3) that is sent unprocessed during authorization but omitted when refreshing a token.
    • state — a string value used to maintain the state between the request and the callback. Shouldn't be modified on the broker's server and should return to the callback unchanged.
    • lang — a parameter on demand, transfers the locale of the TradingView platform, which a trader uses at the time of authorization from the list ar, br, de, en, es, fr, he, hu, id, in, it, ja, kr, ms, pl, ru, th, tr, uk, vi, zh.
  5. The broker's server gives a page with an authorization form and prompts the user to enter their credentials.
  6. The broker's server authenticates and authorizes the user after submitting the form.
  7. If successful, the broker's server redirects the request to redirect_uri with GET parameters:
    • code — an authorization code with a short expiration time, which will subsequently be exchanged for an access token.
    • state — the value of the state field from the original authorization request. Should return unchanged.
  8. The TradingView server sends a POST request for an access token in the application/x-www-form-urlencoded format to the token endpoint of the broker's server with the following parameters:
    • grant_type — the value always equal to authorization_code.
    • code — authorization code obtained from a response to authorization request.
    • client_id — a unique identifier of the client.
    • client_secret — a unique client secret. This parameter has been added for compatibility with the Auth0 service, where it is required.
    • redirect_uri — the same Redirect URI as in the authorization request.
  9. The broker's server sends a response to a request for an access token with the following fields in its body:
    • token_type — the value must be bearer.
    • access_token — access token's that will be used in REST requests to the broker's server.
    • expires_in — optimal token lifetime in seconds, should be in the range of 15-120 minutes.
    • refresh_token — a token that is exchanged for a new access token before the expiration of the current access token.
    • refresh_token_expires_in — optimal refresh token lifetime in seconds, recommended value is 48 hours.
info

The client_id and client_secret for each of the six environment connections must be unique, this is a requirement of our security team. The TradingView website in the sandbox or production can be connected to only one broker's environment at a time.

Example Access Token response​


{
  "access_token" : "eyJhbfGujudUf.eyJvYWEiOiIw[omitted for brevity]",
  "expires_in": 1200,
  "token_type": "Bearer",
  "refresh_token": "86fy7fa3d2-5e13-4736-86031-9ehiyiufrow0b",
  "refresh_token_expires_in": 2400
}

Token refreshing​

When the access token expiration is approaching, TradingView automatically starts the token renewal procedure. A request for a token endpoint is sent to the broker's server with the following parameters:

  • grant_type — the value will always be refresh_token.
  • refresh_token — a refresh token received in the same request as the current access token.
  • client_secret — the value of the unique client secret provided by the broker.

The response is expected to be the same as for the request to obtain an access token during the initial authorization.

info

Note that the refresh_token should have a longer lifetime than the access_token for a correct token renewal.

Authorization page​

info

The authorization process takes place in a separate tab. It will close in 240 seconds after opening, even if no access token has been received. You should not require the user to do anything on this tab other than enter credentials.

The default requirements for the login page are listed below:

  • Integration authorization must be the only offered action on the authorization page. When the user clicks the Connect button in the Trading Panel, the broker login page with fields to enter credentials should be displayed.
  • All login options (including Social Login) must be supported.
  • The page should not display any information irrelevant to the login, such as download links for applications or links to external charts.
  • The page should not have layout bugs. For example, changing between landscape and portrait orientation should not affect the UI/UX. The web view should adapt to mobile devices, ensuring text does not extend beyond the screen size.
  • The authorization page should be adapted to both light and dark themes.
info

TradingView mobile applications use embedded webview where the TradingView application theme color is used. If a dark theme is selected, there may be problems with displaying text written in black font.

Logout flow​

The expected logout flow is as follows. Whenever a user clicks the logout button in the Trading Panel, the user session is expected to be terminated. The credentials must be required during the next login attempt.

info

The absence of the correct logout functionality could be a blocker for the integration release. As it restricts a smooth switch between broker accounts on TradingView and creates security issues.

Cannot get mappings error​

The Cannot get mappings: Symbol Search initialization failed issue appears when you use a datafeed that has no available trading symbols. To fix this issue, add the following query parameter to the address bar and reload the page:

?ws_host=master-charts.xstaging.tv&ss_host=staging-master-search.tradingview.com