Version 3.5.2 reads charts, studies, and replay sessions
TradingView-API connects a Node.js program to TradingView chart and quote sessions. The package exposes clients for charts, built-in and Pine indicators, drawing retrieval, market search, technical analysis, and replay. Its examples show live updates for a symbol, switching markets and timeframes, attaching studies, and stepping through historical periods. That is useful when a strategy depends on a TradingView study rather than a calculation already available in a general market-data library.
The project also reaches into account-bound features. The README claims support for premium and invite-only indicators, drawings, unlimited simultaneous indicators, and date ranges. Example code passes a sessionid token and signature cookie into the client. Version 3.5.2 added search pagination and handling for unexpected HTTP errors such as 429 responses. These are practical capabilities, yet each one depends on behavior controlled by TradingView rather than a stable interface described by this repository.
Two cookies separate public charts from authenticated features
A public chart is short to start: create a client, open a chart session, set a market such as BINANCE:BTCEUR, and listen for updates. Market and indicator search functions also have small examples. Authenticated paths use 2 values named SESSION and SIGNATURE in the sample environment file. Developers must decide how to obtain, store, rotate, and revoke those account cookies without leaking them into logs or source control.
The included login example accepts a TradingView username and password and returns session values. Open issue 202 shows why that is a weak automation boundary: TradingView returned a request to complete a CAPTCHA, even with valid credentials. Issue 222 reports cookies being rejected as wrong or expired. A service built on this client should expect authentication to stop working and should fail closed, notify an operator, and keep trading credentials separate from the data reader.
What happened when we ran it
Our sandbox installed 310 npm packages in 17 seconds and occupied 81 MB. The repository at commit 5baea86 contained 54 files, roughly 5,144 lines of source, and 0.4 MB checked out. There was no build script or target, so the harness skipped that step. The scan found 1 CI workflow, a tests directory, and no Dockerfile.
Vitest completed in 20 seconds: 50 tests passed, none failed, and 16 were skipped out of 66. That is a useful result because the suite reaches chart, indicator, quote-session, replay, search, and authentication-related code. The skipped 16 cases still leave part of the claimed surface unproved by this run. We also did not measure quote latency, data accuracy, reconnect behavior, or request limits, so the test result should not be read as a market-data service guarantee.
The dependency audit found 17 known vulnerabilities
The same npm install produced 17 audit findings: 1 critical, 12 high, 2 moderate, and 2 low. Those numbers are the clearest reason to keep the package out of a privileged process until the dependency tree has been reviewed and remediated. A passing 50-test subset cannot answer whether a published advisory is exploitable in a particular deployment. Pin the lockfile, inspect each advisory, and expose only the narrow data output the rest of the application needs.
Remote behavior adds another failure class. Issue 312 reports a 60,000 ms WebSocket connection timeout, while issue 236 describes a session freezing after 30 pings without an error event. The reports do not establish one shared cause, and the latter is older. They still show the cases an operator should simulate: connection refusal, silent stalls, service throttling, expired cookies, and partial updates. Put a watchdog around the feed and reject stale timestamps before an alert or strategy consumes them.
One sentence of docs leaves the examples carrying the API
The README gives installation, a feature checklist, and links to the examples. docs/DOCS.md contains only the sentence that the project is JSDoc-ed. There are 15 example files covering charts, indicators, drawings, replay, search, login, custom timeframes, and error handling, which is better than a blank repository. Still, a buyer has to read example code and source comments to learn object lifecycles, event order, retries, limits, and the shape of returned data.
That documentation style raises the cost of upgrades. The package declares Node 14 or newer, uses CommonJS exports, and has no compilation step to catch consumer type mismatches. Issue 235 asks for a TypeScript implementation, while the current source is JavaScript. For a small internal collector, tests around your own symbols and studies can fill the gap. A shared platform needs an internal wrapper and contract tests so application code does not spread package-specific session objects everywhere.
June code activity and 101 open items show mixed health
GitHub listed 4,789 stars, 101 combined open issues and pull requests, and a last push on June 23, 2026. The latest release, v3.5.2, was published October 5, 2025. Code activity continued after that release, including June work to stabilize indicator CI tests, and open pull requests were updated in July and August 2026. The project is active, although the large queue and old unanswered bug reports weaken the support story.
TradingView-API makes sense when TradingView itself is the required data surface and a team can own the adapter. Our 17-second install and passing 50-test result make a trial cheap. The 17 audit findings, thin written manual, cookie problems, and WebSocket reports make direct use inside an execution engine a poor bet. Place it behind a small process, validate incoming timestamps and values, record disconnects, and keep an alternative feed ready for any decision that cannot wait.