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 Market 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: Market Data
paths:
/quotes:
get:
summary: Quotes
operationId: getQuotes
tags:
- Market Data
description: 'Get current prices of the instrument.
The `bid` and `ask` fields are required, and the `buyPipValue` and `sellPipValue` fields
are desirable if the account currency is different from the currency of the instrument.
The same values should be sent for these fields if different values for buying and selling are not supported.'
parameters:
- $ref: '#/components/parameters/locale'
- $ref: '#/components/parameters/queryAccountId'
- name: symbols
description: Comma separated symbol list.
in: query
schema:
type: string
required: true
security:
- PasswordBearer: []
- OAuth2Bearer: []
responses:
200:
description: response
content:
application/json:
schema:
oneOf:
- $ref: '#/components/schemas/QuotesResponse'
- $ref: '#/components/schemas/ErrorResponse'
/stream/quotes:
get:
summary: Stream Quotes
operationId: streamQuotes
tags:
- Market Data
description: 'Stream current prices of the instrument.
The `bid` and `ask` fields are required, and the `buyPipValue` and `sellPipValue` fields
are desirable if the account currency is different from the currency of the instrument.
The same values should be sent for these fields if different values for buying and selling are not supported.'
parameters:
- $ref: '#/components/parameters/locale'
- $ref: '#/components/parameters/queryAccountId'
- name: symbols
description: Comma separated symbol list.
in: query
schema:
type: string
required: true
security:
- PasswordBearer: []
- OAuth2Bearer: []
responses:
200:
description: response
content:
application/json:
schema:
oneOf:
- $ref: '#/components/schemas/QuotesMessage'
- $ref: '#/components/schemas/PingMessage'
- $ref: '#/components/schemas/ErrorMessage'
/depth:
get:
summary: Depth
operationId: getDepth
tags:
- Market Data
description: Get current depth of market for the instrument. Optional.
parameters:
- $ref: '#/components/parameters/locale'
- $ref: '#/components/parameters/queryAccountId'
- name: symbol
description: Instrument name.
in: query
schema:
type: string
required: true
security:
- PasswordBearer: []
- OAuth2Bearer: []
responses:
200:
description: response
content:
application/json:
schema:
oneOf:
- $ref: '#/components/schemas/DepthResponse'
- $ref: '#/components/schemas/ErrorResponse'
/stream/depth:
get:
summary: Stream Depth
operationId: streamDepth
tags:
- Market Data
description: Stream current depth of market for the instrument. Optional.
parameters:
- $ref: '#/components/parameters/locale'
- $ref: '#/components/parameters/queryAccountId'
- name: symbol
description: Instrument name.
in: query
schema:
type: string
required: true
security:
- PasswordBearer: []
- OAuth2Bearer: []
responses:
200:
description: response
content:
application/json:
schema:
oneOf:
- $ref: '#/components/schemas/Depth'
- $ref: '#/components/schemas/PingMessage'
- $ref: '#/components/schemas/ErrorMessage'
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
Status:
title: Status
type: string
enum:
- ok
- error
DepthResponse:
title: DepthResponse
type: object
properties:
s:
$ref: '#/components/schemas/OkStatus'
d:
$ref: '#/components/schemas/Depth'
required:
- s
- d
additionalProperties: false
ErrorResponse:
title: ErrorResponse
$ref: '#/components/schemas/Error'
DepthItem:
title: DepthItem
type: array
description: Array with two numeric elements - price and volume.
items:
type: number
minItems: 1
ErrorMessage:
title: ErrorMessage
$ref: '#/components/schemas/Error'
additionalProperties: false
Quotes:
title: Quotes
type: array
items:
type: object
description: Price response for an instrument
properties:
s:
$ref: '#/components/schemas/Status'
n:
description: Symbol name. Should be equal to the requested one.
type: string
example: EURUSD
v:
$ref: '#/components/schemas/SingleQuote'
required:
- n
- v
additionalProperties: false
minItems: 1
QuotesResponse:
title: QuotesResponse
type: object
properties:
s:
$ref: '#/components/schemas/OkStatus'
d:
$ref: '#/components/schemas/Quotes'
required:
- s
- d
additionalProperties: false
Locale:
title: Locale
description: Locale (language) id. This parameter is required for trading integration only.
type: string
enum:
- ar_AE
- br
- de_DE
- en
- es
- fr
- he_IL
- hu_HU
- id
- in
- it
- ja
- kr
- ms_MY
- pl
- ru
- th_TH
- tr
- uk
- vi_VN
- zh_CN
- zh_TW
QuotesMessage:
title: QuotesMessage
$ref: '#/components/schemas/Quotes'
OkStatus:
title: OkStatus
type: string
description: Status will always be `ok`.
enum:
- ok
example: ok
PingMessage:
title: PingMessage
type: object
description: A ping message to ensure that the connection persists. Must be sent every 5 seconds if there were no entity updates.
properties:
s:
$ref: '#/components/schemas/OkStatus'
required:
- s
SingleQuote:
title: SingleQuote
type: object
description: Price and restriction data for an instrument.
properties:
ask:
description: Ask price.
type: number
example: 1.13836
askSize:
description: Ask size.
type: number
example: 200
bid:
description: Bid price.
type: number
example: 1.13834
bidSize:
description: Bid size.
type: number
example: 100
last:
description: Last price.
type: number
example: 1.13845
lastSize:
description: Last size.
type: number
example: 300
buyPipValue:
description: Value of 1 pip in the account currency, used for calculating risks and trade value in the Order dialog for buy orders.
type: number
example: 1
sellPipValue:
description: Value of 1 pip in the account currency, used for calculating risks and trade value in the Order dialog for sell orders.
type: number
example: 1
hardToBorrow:
description: Specify if the instrument is hard to borrow.
type: boolean
default: false
notShortable:
description: Specify if the instrument is not shortable.
type: boolean
default: false
halted:
description: Specify if the instrument is halted.
type: boolean
default: false
required:
- ask
- bid
additionalProperties: false
Depth:
title: Depth
type: object
description: Depth of market for an instrument.
properties:
asks:
description: Array of arrays with two numeric elements - price and volume. Must be sorted by `price` in ascending order.
type: array
items:
$ref: '#/components/schemas/DepthItem'
bids:
description: Array of arrays with two numeric elements - price and volume. Must be sorted by `price` in ascending order.
type: array
items:
$ref: '#/components/schemas/DepthItem'
required:
- asks
- bids
additionalProperties: false
example:
asks:
- - 45.1
- 100
- - 48.4
- 120
bids:
- - 24.7
- 80
- - 35.6
- 30
parameters:
locale:
name: locale
in: query
required: true
description: Locale (language) id.
schema:
$ref: '#/components/schemas/Locale'
queryAccountId:
name: accountId
in: query
description: Account identifier.
schema:
type: string
required: true
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"