TradingView OAuth Scopes

generated: '2026-11-05'
method: derived
source: openapi/tradingview-broker-rest-api-openapi.yml
schemes:
- name: OAuth2Bearer
  source: openapi/tradingview-broker-rest-api-openapi.yml
  flows:
  - flow: authorizationCode
    authorizationUrl: https://your-rest-implementation.com/api/authorize
    tokenUrl: https://your-rest-implementation.com/api/oauth/token
  description: |-
    TradingView supports OAuth 2 Authorization Code flow (standard) and OAuth 2 Authorization Code flow with PKCE, as described in [RFC 6749](https://tools.ietf.org/html/rfc6749) and [RFC 7636](https://tools.ietf.org/html/rfc7636), respectively.
    After performing authorization, the access token is sent with every request in the `Authorization` header.

    **Code Flow:**

    For OAuth 2 Code Flow the broker provides TradingView with the following OAuth 2 application parameters:

    Application parameter | Description | Example value
    ----------------------|-------------|----------------------------------------
    client id             | A unique client identifier | sQeww4FgtythHTUrhrfMo9rRTq |
    client secret         | A client secret | 45dd67oi56ds678st6788dffdyu |
    authorization URI     | An authorization endpoint URI |https://your-rest-implementation.com/oauth/authorize |
    token URI             | A token endpoint URI | https://your-rest-implementation.com/oauth/token |
    logout URI (optional) | A logout URI | https://your-rest-implementation.com/oauth/logout |
    scope                 | A scope of the access request as a list of space-delimited, case-sensitive strings | read trade profile |

    TradingView provides the broker with two redirect URIs, one for the staging environment and the other for the production environment.

    TradingView also provides a `redirect_uri` URI if the broker supports user logout with a redirect.

    **Note**: The `redirect_uri` parameter should be verified by the broker's OAuth service, and should be whitelisted on the broker's side.

    **PKCE:**

    TradingView supports OAuth 2 Authorization Code Flow with PKCE as an extension of the standard Code Flow.

    In the Authorization Code flow with PKCE, TradingView binds the authorization request and the token request using a one-time secret (`code_verifier`).
    The following parameters are added:
    - Authorization Request: `code_challenge`, `code_challenge_method`
    - Token Request: `code_verifier`

    When PKCE is not used, PKCE-only parameters must be omitted.

    *Authorization Request*

    TradingView sends the Authorization Request according to [OAuth 2 specification, 4.1.1](https://tools.ietf.org/html/rfc6749#section-4.1.1)
    and [Proof Key for Code Exchange by OAuth Public Clients, 4.3](https://datatracker.ietf.org/doc/html/rfc7636#section-4.3).
    The following parameters will be in the query part of the authorization URI:

    OAuth2 parameter | Description
    -----------------|------------
    response_type    | Response type. The value will be set to `code` |
    client_id        | A client identifier string provided by the broker |
    redirect_uri     | [Redirection Endpoint](https://tools.ietf.org/html/rfc6749#section-3.1.2) |
    scope            | A scope of the access request if it is provided by the broker |
    code_challenge   | (PKCE only) PKCE code challenge derived from `code_verifier` |
    code_challenge_method | (PKCE only) PKCE challenge method. TradingView uses `S256` |
    state            | [A literal string](https://tools.ietf.org/html/rfc6749#section-4.1.1) that the broker should return back to TradingView without changes in the authorization response

    **Note**: The `redirect_uri` parameter should be verified by the broker's OAuth service, and should be whitelisted on the broker's service.

    TradingView could send the `lang` parameter additionally if it is required by the broker, with the following possible values:
    `ar`, `br`, `de`, `en`, `es`, `fr`, `he` ,`hu`, `id`, `in`, `it`, `ja`, `kr`, `ms`, `pl`, `ru`, `th`, `tr`, `uk`, `vi`, `zh`.

    If all the parameters of the authorization request are valid and access is granted, the broker issues an authorization code and redirects to the redirect URI
    with the following parameters added to the request URI component:

    OAuth2 parameter | Description
    -----------------|------------
    code  | The authorization code. It must expire shortly after its release to prevent the risk of leakage |
    state | The exact value which was sent in the authorization request |

    *Access Token Request*

    TradingView makes an Access Token Request by sending the following parameters using the `application/x-www-form-urlencoded` format:

    OAuth2 parameter | Description
    -----------------|------------
    grant_type       | The grant type. The value will be set to `authorization_code` |
    client_id        | A client identifier string provided by the broker |
    client_secret    | A client secret string provided by the broker |
    code             | The authorization code received from the broker |
    redirect_uri     | The same redirect URI used in the Authorization Request |
    code_verifier    | (PKCE only) PKCE code verifier used to validate `code_challenge` |

    After successful verification of the authorization code broker issues an access token,
    a refresh token and responds to the access token request as follows:

    OAuth2 parameter         | Description
    -------------------------|------------
    access_token             | The access token which will be used in every request to the API |
    refresh_token            | Token used to obtain new access tokens |
    token_type               | Token type. Should be set to `bearer` |
    expires_in               | The life time of the access token in seconds |
    refresh_token_expires_in | The life time of the refresh token in seconds |

    The `expires_in` and `refresh_token_expires_in` parameters are optional, but are recommended to provide
    a more secure environment for integration users.

    *Refresh Request*

    To refresh the access token TradingView makes a Refresh Request to the token endpoint using the `application/x-www-form-urlencoded` format with the following parameters:

    OAuth2 parameter | Description
    -----------------|------------
    grant_type       | The grant type. The value will be set to `refresh_token` |
    refresh_token    | The refresh token issued by the broker |
    client_secret    | The client secret value provided by the broker |

    If all parameters are valid, the broker issues a new access token and, if necessary,
    a new refresh token and responds to the request as described in the *Access token request* section above.

    *Logout Request*

    To log the user out of the integration, TradingView makes a Logout Request to the logout endpoint with the following query string parameters:

    OAuth2 parameter | Description | Example
    -----------------|-------------|----------
    client_id        | A client identifier string provided by the broker |
    redirect_uri     | The url where the user should be redirected to after logging out | https://www.tradingview.com/trading/logout-redirect/
- name: ServerOAuth2Bearer
  source: openapi/tradingview-broker-rest-api-openapi.yml
  flows:
  - flow: clientCredentials
    tokenUrl: https://your-rest-implementation.com/api/authorize/token
  description: |-
    This authentication flow is used for server-to-server requests where authentication needs to be done without human intervention.
    It can be used with the [/history](#operation/getHistory), [/symbol_info](#operation/getSymbolInfo), [/streaming](#operation/streaming)
    and [/groups](#operation/getGroups) endpoints.

    JSON Web Token (JWT) is used to securely transmit information between broker and TradingView.
    More information about JWT can be found [here](https://jwt.io/introduction/).

    ### Application and OAuth2 parameters

    The broker provides the following application and OAuth2 parameters to TradingView:

    Application parameter | Description | Example value
    -----------------|-------------|---------------
    AppUrl | A URL uniquely representing broker's application | https://your-rest-implementation.com
    UserId | A user identifier for which the access token will be issued | testuser1

    OAuth2 parameter | Description | Example value
    -----------------|-------------|---------------
    client_id | A unique client Identifier | FGGH7-TRVC3-ECDD2-CDHRG3-FYUDG5 |
    client_secret | Secret code | adfegywrtyw |
    token_url | An url to which the access token request will be sent | https://your-rest-implementation.com/authorize/token
    grant_type | Indicates the type of grant being presented in exchange for an access token  | urn:your-broker:oauth:grant-type:personal-jwt

    ### X.509 Certificate
    The broker provides a valid X.509 certificate to TradingView for signing JWT.


    ### JSON Web Token
    JWT for the access token request is created with the following headers and claims:

    Header | Description | Standard | Sample Value
    -------|-----------|------------|---------------
    x5t | Thumbprint of provided X.509 certificate used for signing JWT | [RFC 7515](https://tools.ietf.org/html/rfc7515#section-4.1.7) | 935093f1690900asdfd98626dfw35fa22b41d9dfd
    alg | Algorithm used to sign JWT. RS256 is only supported at the moment | [RFC 1518](https://tools.ietf.org/html/rfc7518#page-6) | RS256

    Claim | Description | Sample Value
    ------|-------------|-------------
    iss | Issuer - Value should be client_id | FGGH7-TRVC3-ECDD2-CDHRG3
    sub | UserId - Value should be the UserId for which token is needed | testuser1
    exp | Expiry - Value should be a Unix time stamp indicating expiry of the token | 1549465914
    aud | Audience - Value should be the token_url | https://your-rest-implementation.com/authorize/token
    spurl | AppUrl - The AppUrl of your application | https://your-rest-implementation.com

    ### Requesting the access token
    TradingView sends a POST request to the `token_url` to obtain an access token.
    The `client_id` and `client_secret` are included as parameters in the request body.
    The JWT is sent in a parameter named `assertion`.

    #### Example Access Token request

        POST /token HTTP/1.1
        Host: sim.logonvalidation.net
        Content-Type: application/x-www-form-urlencoded

        grant_type=urn%3Ayour-broker%3Aoauth%3Agrant-type%3Apersonal-jwt
        &assertion=eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0.eyJpc3Mi[...omitted for brevity...]
        &client_id=1234-5678-9101
        &client_secret=abcdefghijklmn

    The response to this request should contain an `access_token`. A `refresh_token` is optional and can be omitted:

    #### 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
        }
- name: ServerOAuth2JWT
  source: openapi/tradingview-broker-rest-api-openapi.yml
  flows:
  - flow: clientCredentials
    tokenUrl: https://your-rest-implementation.com/api/authorize/token
  description: |-
    This authentication flow is used for server-to-server requests where
    authentication needs to be done without human intervention.  It can be
    used with the [/history](#operation/getHistory),
    [/symbol_info](#operation/getSymbolInfo),
    [/streaming](#operation/streaming) and [/groups](#operation/getGroups)
    endpoints.

    JSON Web Token (JWT) is used to securely transmit information between
    broker and TradingView.  More information about JWT can be found
    [here](https://jwt.io/introduction/).

    This flow is described in Section 2.2 of
    [RFC 7523](https://datatracker.ietf.org/doc/html/rfc7523#section-2.2).

    ### Application and OAuth2 parameters

    The broker provides the following application and OAuth2 parameters to
    TradingView:

    Application parameter | Description                                                 | Example value
    ----------------------|-------------------------------------------------------------|---------------
    Audience              | A URL uniquely representing broker's application            | https://your-rest-implementation.com
    UserId                | A user identifier for which the access token will be issued | testuser1

    OAuth2 parameter | Description                                           | Example value
    -----------------|-------------------------------------------------------|---------------
    client_id        | A unique client identifier                            | FGGH7-TRVC3-ECDD2-CDHRG3-FYUDG5
    token_url        | A URL to which the access token request will be sent  | https://your-rest-implementation.com/authorize/token

    ### X.509 Certificate

    The broker provides a valid X.509 certificate and RSA private key to
    TradingView for signing JWT.

    ### JSON Web Token

    JWT for the access token request is created with the following headers
    and claims:

    Header | Description                                                       | Standard                                                  |Sample Value
    -------|-------------------------------------------------------------------|-----------------------------------------------------------|--------------
    x5t    | Thumbprint of X.509 certificate used for signing JWT              | [RFC 7515](https://datatracker.ietf.org/doc/html/rfc7515) | 8e098221574da76cb97db539f69ae09d3c770ba9
    alg    | Algorithm used to sign JWT. RS256 is only supported at the moment | [RFC 7518](https://datatracker.ietf.org/doc/html/rfc7518) | RS256

    Claim | Description                                                               | Sample Value
    ------|---------------------------------------------------------------------------|-------------
    iss   | Issuer - Value should be client_id                                        | FGGH7-TRVC3-ECDD2-CDHRG3-FYUDG5
    sub   | UserId - Value should be the UserId for which token is needed             | testuser1
    exp   | Expiry - Value should be a Unix time stamp indicating expiry of the token | 1745166000
    aud   | Audience - Value should be the token_url                                  | https://your-rest-implementation.com/authorize/token
    jti   | JWT ID - An identifier for the token, must be unique per request          | 7061d388-a4c0-4cd6-89f7-919567e38cfb

    ### Requesting the access token

    TradingView sends a POST request to the `token_url` to obtain an access
    token.  The `client_id` and `audience` are included as parameters in the
    request body.  The JWT is sent in a parameter named `client_assertion`.

    #### Example Access Token request

        POST /api/authorize/token HTTP/1.1
        Host: your-rest-implementation.com
        Content-Type: application/x-www-form-urlencoded

        grant_type=client_credentials
        &client_id=FGGH7-TRVC3-ECDD2-CDHRG3-FYUDG5
        &client_assertion=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOi[...omitted for brevity...]
        &client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
        &audience=https://your-rest-implementation.com

    The response to this request should contain an `access_token`.

    #### Example Access Token response

        {
          "access_token" : "eyJhbfGujudUf.eyJvYWEiOiIw[...omitted for brevity...]",
          "token_type": "Bearer",
          "expires_in": 1200
        }
scopes:
- scope: general
  description: permission to perform all requests
  flows:
  - authorizationCode
  - clientCredentials
  sources:
  - openapi/tradingview-broker-rest-api-openapi.yml