TradingView API Guide: Choose the Right Chart Integration

“TradingView API” can refer to several different products. Advanced Charts is a library you embed with your own datafeed; a hosted widget is an embeddable display; broker integration is a separate trading workflow. Start by choosing the product that matches your application.

Choose an integration surface

Use TradingView's Advanced Charts documentation to check access, licensing, and the version you have received. Do not assume a fixed approval time or that downloading chart files includes production market-data rights.

The library FAQ explains that Advanced Charts and Trading Platform do not run Pine Script. They also do not reproduce every feature of tradingview.com. A Pineify-generated Pine script is intended for TradingView's Pine environment, not direct execution inside an embedded chart library.

Connect the library to data you can use

You supply symbol information, historical bars, and realtime updates. Choose either a backend implementing the supported UDF protocol with its adapter, or a custom Datafeed API implementation. These are integration choices, not a requirement to subclass the UDF adapter and override selected methods.

Before implementing the adapter, define your provider's symbol identifiers, timestamps, sessions, timezones, supported resolutions, and data entitlements. Keep provider credentials on the server when they are not intended for public browser use.

Implement and verify historical requests

Follow the required Datafeed API methods for onReady, symbol resolution, getBars, and subscriptions. Use the supplied request parameters and resolved symbol information rather than an invented symbolInfo.symbol contract.

For getBars, verify ordering, duplicate timestamps, requested history, and an accurate no-data response. Bar timestamps use milliseconds; daily and higher-period conventions also need to match the documented trading-day alignment. An error callback should report a failed request; silently returning unrelated cached bars can misrepresent the market.

Manage realtime subscriptions

subscribeBars asks your datafeed to begin delivering updates; it does not create a network connection for you. Your implementation owns the transport, aggregation, and lifecycle. Keep subscriptions separate by their identifiers and stop them when unsubscribeBars is called.

An update with the most recent bar's timestamp replaces that bar; a later timestamp adds a new one. Do not send earlier bars through the realtime callback to rewrite history. Consult the datafeed troubleshooting guide when the chart reports cache or time violations.

Keep trading integration separate

Rendering a chart does not give it access to a user's broker account. Chart trading needs the appropriate Trading Platform integration and a broker backend. An arbitrary keyboard shortcut should not be described as a ready-made secure execution API.

Define order validation, account permissions, confirmation behavior, errors, and reconciliation in the trading system. Test with the broker's supported paper environment before considering live execution.

Validate the application, not a fixed bar-count target

Test an empty history response, partial history, a market close, a reconnect, a symbol change, and multiple active subscriptions. Compare bars with the licensed source and inspect browser and backend errors.

There is no universal 5,000-bar safe limit established by this article. Measure loading and memory behavior on your supported devices and data sizes. Local development configuration and production HTTPS requirements should be handled according to your deployment and provider rules, not a blanket claim that every HTTP development server silently fails.

For persistence, use the save/load interfaces documented for your library version and choose storage appropriate to the user's account and privacy needs. Do not treat local browser storage as cross-device synchronization.