Every API here is available over the APIs.io API and to AI agents over MCP.
openapi: 3.2.0
info:
version: 1.21.0
title: TradingView REST API Specification for Brokers Data…
description: '## Overview
This API is to be implemented by the Brokers in order to connect their backend systems to TradingView, that acts as a frontend. Check the info page for more info and use the contact form there if you have any questions. ### Types of requests
There are two types of requests — client and server. Client requests are executed at the browser. Server requests are initiated from the TradingView servers. If your integration does not imply brokerage data stream connection to the TradingView website -
then there won''t be any server requests. #### Clients requests
The two possible ways of sending updates to the client''s side are either done by making use of client regularly polling endpoints,
or by opening a streaming connection and pushing updates. ##### HTTP requests
From the browser TradingView requests the info (list of orders and positions, balance info, etc.) from the broker’s server. The requests are sent periodically and the intervals can be set by using the /config endpoint. After that, TradingView compares the new data with the previous answer and calculates the difference. If the status of the order/position changes or new data appears - the user will see a notification and the changes
will display in the Account manager on the website. Requests to the endpoints for placing/modifying orders, positions closing, etc. occur only after actions made by the user. The /quotes endpoint retrieves the current bid/ask from the broker. The /depth endpoint retrieves Level 2 market data. ##### HTTP streaming
If the integration uses HTTP streaming endpoints, the connections to them are established once at the start of a session. The http-streaming consists of messages separated with line breaks. The content of the messages must be in Compact JSON format, i.e. should not contain any line breaks, except a line break at the very end
which will act as a message separator. There are four types of messages:
- Entities snapshot
- Entities updates
- Ping
- Error
Please refer to the streaming endpoints for more details. #### Server requests
In case if a Broker provides any Forex or CFD trading access for its clients it will require connection
of its own market data at TradingView. In order to make it possible, you will need to implement the following endpoints -
/symbol_info, /history and /streaming. Data requests are sent from different TradingView servers. Usually, at least 4 servers are used. The historical data is cached on TradingView servers and loaded to the client browser from our servers. ### Restricting access to data
By default, the broker symbols will be available in the symbol search at TradingView and all the community
will have access to your data streams without any limitation. In order to limit the access to your data streams
please use the following endpoints - /groups and /permissions. You can find more information about restricting access to the data in the description of these endpoints. ### Change log
1.21.0 Added time window and cursor pagination to the /executions and /ordersHistory endpoints. Added new `startTime`, `endTime` and `cursor` query parameters and a new `nextPageCursor` field to the responses. The `maxCount` parameter limits the page size. The `instrument` parameter of the /executions endpoint is no longer required. Added new `invalid_cursor` error type. 1.20.0 Added new `grossPnl`, `netPnl`, `swap` and `conversion` fields to Execution in the /getExecutions endpoint''s response. 1.19.0 Added support for unpaired exit levels. Added new flag: `supportUnpairedExitLevels`. 1.18.0 Added a new `digitalSignature` field to the /modifyPosition and /modifyIndividualPosition endpoints. 1.17.0 Added new typespecs `algorithmic`. 1.16.0 Added OAuth 2.0 JWT Authorization. 1.15.0 Added new `option` type and new fields specific to options: `lotsize`, `option-product`, `option-type`, `option-style`, `strike`, `underlying-symbol` to the /symbol_info endpoint.'
servers:
- url: https://your-rest-implementation.com/api
description: Your REST API implementation url. Change it to your real REST API url.
tags:
- name: Data Permissions
paths:
/groups:
get:
summary: Groups
operationId: getGroups
tags:
- Data Permissions
description: 'Get a list of possible groups of symbols.
A group is a set of symbols that share a common access level. Any user can have access to any number of such groups.
In case your data integration does not require separating symbols into several groups, implementing this endpoint is still mandatory. You will be able to add a single group and place all symbols there.
**IMPORTANT:**
Please plan your symbol grouping carefully. Groups cannot be deleted, you can only remove all the symbols from there.
**LIMITATIONS:**
Each integration is limited to have up to 10 symbol groups.
Each symbol group is limited to have up to 10K symbols in it.
You cannot put the same symbol into 2 different groups.
This endpoint allows you to specify a list of groups, and the /permissions endpoint specifies
which groups are available for the certain user.
When TradingView user logs into his broker account - he will gain access to one or more groups,
depending on the /permissions endpoint.
At the /symbol_info endpoint TradingView adds the GET argument `group`
with the name of the group. Thus, TradingView will receive information about which group each symbol belongs to.'
security:
- PasswordBearer: []
- ServerOAuth2Bearer: []
- ServerOAuth2JWT: []
responses:
200:
description: response
content:
application/json:
schema:
oneOf:
- $ref: '#/components/schemas/GroupListResponse'
- $ref: '#/components/schemas/ErrorResponse'
/permissions:
get:
summary: Permissions
operationId: getPermissions
tags:
- Data Permissions
description: 'Get a list of symbol groups allowed for the user.
It is only required if you use groups of symbols to restrict access to instrument''s data.'
security:
- PasswordBearer: []
- OAuth2Bearer: []
responses:
200:
description: response
content:
application/json:
schema:
oneOf:
- $ref: '#/components/schemas/PermissionsResponse'
- $ref: '#/components/schemas/ErrorResponse'
components:
schemas:
Error:
type: object
properties:
s:
type: string
description: Status will always be `error`.
enum:
- error
example: error
errmsg:
type: string
description: Error message.
example: An error occurred.
errtype:
type: string
enum:
- invalid_token
- unauthorized
- forbidden
- server_error
- invalid_cursor
example: invalid_token
description: Represents the error type that occurred.
required:
- s
- errmsg
additionalProperties: false
ErrorResponse:
title: ErrorResponse
$ref: '#/components/schemas/Error'
GroupList:
title: GroupList
type: object
properties:
groups:
type: array
description: 'Each element of this array is an group object.
'
items:
type: object
properties:
id:
description: 'All characters in a group id must be either a lowercase alphabetic character, a number, or an underscore.
A group id should start with the same prefix related to the broker''s name.
'
type: string
required:
- id
additionalProperties: false
additionalProperties: false
example:
groups:
- id: broker_stocks
- id: broker_futures
- id: broker_forex
- id: broker_crypto
PermissionGroups:
title: PermissionGroups
type: object
required:
- groups
properties:
groups:
description: Groups list. Each element of this array is a group identifier.
type: array
items:
type: string
additionalProperties: false
example:
groups:
- broker_futures
- broker_stocks
- broker_forex
PermissionsResponse:
title: PermissionsResponse
type: object
properties:
s:
$ref: '#/components/schemas/OkStatus'
d:
$ref: '#/components/schemas/PermissionGroups'
required:
- s
- d
additionalProperties: false
OkStatus:
title: OkStatus
type: string
description: Status will always be `ok`.
enum:
- ok
example: ok
GroupListResponse:
title: GroupListResponse
type: object
properties:
s:
$ref: '#/components/schemas/OkStatus'
d:
$ref: '#/components/schemas/GroupList'
required:
- s
- d
additionalProperties: false
securitySchemes:
PasswordBearer:
type: http
scheme: bearer
bearerFormat: Bearer ACCESS_TOKEN
description: 'This flow uses login and password to authenticate a user. Username and password are sent as parameters
to the [/authorize](/rest-api-spec/#operation/authorize) endpoint.
If the username and password are valid, then the broker issues an access token
and returns it in the response. The access token is sent with every request in the Authorization header.
'
OAuth2Bearer:
type: oauth2
flows:
authorizationCode:
authorizationUrl: https://your-rest-implementation.com/api/authorize
tokenUrl: https://your-rest-implementation.com/api/oauth/token
scopes:
general: permission to perform all requests
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/
'
ServerOAuth2Bearer:
type: oauth2
flows:
clientCredentials:
tokenUrl: https://your-rest-implementation.com/api/authorize/token
scopes:
general: permission to perform all requests
description: "This authentication flow is used for server-to-server requests where authentication needs to be done without human intervention.\nIt can be used with the [/history](#operation/getHistory), [/symbol_info](#operation/getSymbolInfo), [/streaming](#operation/streaming)\nand [/groups](#operation/getGroups) endpoints.\n\nJSON Web Token (JWT) is used to securely transmit information between broker and TradingView.\nMore information about JWT can be found [here](https://jwt.io/introduction/).\n\n### Application and OAuth2 parameters\n\nThe broker provides the following application and OAuth2 parameters to TradingView:\n\nApplication parameter | Description | Example value\n-----------------|-------------|---------------\nAppUrl | A URL uniquely representing broker's application | https://your-rest-implementation.com\nUserId | A user identifier for which the access token will be issued | testuser1\n\nOAuth2 parameter | Description | Example value\n-----------------|-------------|---------------\nclient_id | A unique client Identifier | FGGH7-TRVC3-ECDD2-CDHRG3-FYUDG5 |\nclient_secret | Secret code | adfegywrtyw |\ntoken_url | An url to which the access token request will be sent | https://your-rest-implementation.com/authorize/token\ngrant_type | Indicates the type of grant being presented in exchange for an access token | urn:your-broker:oauth:grant-type:personal-jwt\n\n### X.509 Certificate\nThe broker provides a valid X.509 certificate to TradingView for signing JWT.\n\n\n### JSON Web Token\nJWT for the access token request is created with the following headers and claims:\n\nHeader | Description | Standard | Sample Value\n-------|-----------|------------|---------------\nx5t | Thumbprint of provided X.509 certificate used for signing JWT | [RFC 7515](https://tools.ietf.org/html/rfc7515#section-4.1.7) | 935093f1690900asdfd98626dfw35fa22b41d9dfd\nalg | Algorithm used to sign JWT. RS256 is only supported at the moment | [RFC 1518](https://tools.ietf.org/html/rfc7518#page-6) | RS256\n\nClaim | Description | Sample Value\n------|-------------|-------------\niss | Issuer - Value should be client_id | FGGH7-TRVC3-ECDD2-CDHRG3\nsub | UserId - Value should be the UserId for which token is needed | testuser1\nexp | Expiry - Value should be a Unix time stamp indicating expiry of the token | 1549465914\naud | Audience - Value should be the token_url | https://your-rest-implementation.com/authorize/token\nspurl | AppUrl - The AppUrl of your application | https://your-rest-implementation.com\n\n### Requesting the access token\nTradingView sends a POST request to the `token_url` to obtain an access token.\nThe `client_id` and `client_secret` are included as parameters in the request body.\nThe JWT is sent in a parameter named `assertion`.\n\n#### Example Access Token request\n\n POST /token HTTP/1.1\n Host: sim.logonvalidation.net\n Content-Type: application/x-www-form-urlencoded\n\n grant_type=urn%3Ayour-broker%3Aoauth%3Agrant-type%3Apersonal-jwt\n &assertion=eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0.eyJpc3Mi[...omitted for brevity...]\n &client_id=1234-5678-9101\n &client_secret=abcdefghijklmn\n\nThe response to this request should contain an `access_token`. A `refresh_token` is optional and can be omitted:\n\n#### Example Access Token response\n {\n \"access_token\" : \"eyJhbfGujudUf.eyJvYWEiOiIw[omitted for brevity]\",\n \"expires_in\": 1200,\n \"token_type\": \"Bearer\",\n \"refresh_token\": \"86fy7fa3d2-5e13-4736-86031-9ehiyiufrow0b\",\n \"refresh_token_expires_in\": 2400\n }\n"
ServerOAuth2JWT:
type: oauth2
flows:
clientCredentials:
tokenUrl: https://your-rest-implementation.com/api/authorize/token
scopes:
general: permission to perform all requests
description: "This authentication flow is used for server-to-server requests where\nauthentication needs to be done without human intervention. It can be\nused with the [/history](#operation/getHistory),\n[/symbol_info](#operation/getSymbolInfo),\n[/streaming](#operation/streaming) and [/groups](#operation/getGroups)\nendpoints.\n\nJSON Web Token (JWT) is used to securely transmit information between\nbroker and TradingView. More information about JWT can be found\n[here](https://jwt.io/introduction/).\n\nThis flow is described in Section 2.2 of\n[RFC 7523](https://datatracker.ietf.org/doc/html/rfc7523#section-2.2).\n\n### Application and OAuth2 parameters\n\nThe broker provides the following application and OAuth2 parameters to\nTradingView:\n\nApplication parameter | Description | Example value\n----------------------|-------------------------------------------------------------|---------------\nAudience | A URL uniquely representing broker's application | https://your-rest-implementation.com\nUserId | A user identifier for which the access token will be issued | testuser1\n\nOAuth2 parameter | Description | Example value\n-----------------|-------------------------------------------------------|---------------\nclient_id | A unique client identifier | FGGH7-TRVC3-ECDD2-CDHRG3-FYUDG5\ntoken_url | A URL to which the access token request will be sent | https://your-rest-implementation.com/authorize/token\n\n### X.509 Certificate\n\nThe broker provides a valid X.509 certificate and RSA private key to\nTradingView for signing JWT.\n\n### JSON Web Token\n\nJWT for the access token request is created with the following headers\nand claims:\n\nHeader | Description | Standard |Sample Value\n-------|-------------------------------------------------------------------|-----------------------------------------------------------|--------------\nx5t | Thumbprint of X.509 certificate used for signing JWT | [RFC 7515](https://datatracker.ietf.org/doc/html/rfc7515) | 8e098221574da76cb97db539f69ae09d3c770ba9\nalg | Algorithm used to sign JWT. RS256 is only supported at the moment | [RFC 7518](https://datatracker.ietf.org/doc/html/rfc7518) | RS256\n\nClaim | Description | Sample Value\n------|---------------------------------------------------------------------------|-------------\niss | Issuer - Value should be client_id | FGGH7-TRVC3-ECDD2-CDHRG3-FYUDG5\nsub | UserId - Value should be the UserId for which token is needed | testuser1\nexp | Expiry - Value should be a Unix time stamp indicating expiry of the token | 1745166000\naud | Audience - Value should be the token_url | https://your-rest-implementation.com/authorize/token\njti | JWT ID - An identifier for the token, must be unique per request | 7061d388-a4c0-4cd6-89f7-919567e38cfb\n\n### Requesting the access token\n\nTradingView sends a POST request to the `token_url` to obtain an access\ntoken. The `client_id` and `audience` are included as parameters in the\nrequest body. The JWT is sent in a parameter named `client_assertion`.\n\n#### Example Access Token request\n\n POST /api/authorize/token HTTP/1.1\n Host: your-rest-implementation.com\n Content-Type: application/x-www-form-urlencoded\n\n grant_type=client_credentials\n &client_id=FGGH7-TRVC3-ECDD2-CDHRG3-FYUDG5\n &client_assertion=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOi[...omitted for brevity...]\n &client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer\n &audience=https://your-rest-implementation.com\n\nThe response to this request should contain an `access_token`.\n\n#### Example Access Token response\n\n {\n \"access_token\" : \"eyJhbfGujudUf.eyJvYWEiOiIw[...omitted for brevity...]\",\n \"token_type\": \"Bearer\",\n \"expires_in\": 1200\n }\n"