TradingView-API: unofficial market data over the charting socket

A client for a private protocol, published as an npm package

The repository description is one line: get real-time stocks from TradingView. Everything else in this project follows from that. There is no TradingView endpoint being documented here, no official key, no quota table. The library speaks the same websocket and HTTP calls the charting front end makes, which is why it can return data for symbols and indicators that have no public API.

The published package is `@mathieuc/tradingview`, version 3.5.2, with `main.js` as its entry point and a Node floor of 14. The dependency list is short and tells you what the transport actually is:

"dependencies": {
  "axios": "^1.5.0",
  "jszip": "^3.7.1",
  "ws": "^7.4.3"
}

`ws` is the websocket client, `axios` handles the HTTP side, and `jszip` is there because TradingView ships Pine script sources and some indicator payloads as zipped archives. There is no headless browser, no DOM shim, no Chromium download. That is why this is cheap to run on a small server where a scraper would not be.

A licensing wrinkle worth knowing before you build on it: `package.json` declares `"license": "ISC"` and names Mathieu Colmon as author, while GitHub reports no license value for the repository itself and the tree has no LICENSE file at the root. For personal and internal use that difference will never matter. If you intend to redistribute it or ship it inside a product, ask which of the two you are being licensed under before you rely on it.

Installing from npm or straight from the branch

The README gives two install paths and the distinction matters more than it looks. The stable channel is the npm registry:

npm i @mathieuc/tradingview

The second path installs the tip of the repository:

npm i github:Mathieu2301/TradingView-API

That second form is the one to reach for when a TradingView change has broken the released version, which happens periodically for a project that depends on an undocumented protocol. It is also the one that can break on a commit nobody has tested. A sensible split is to track the npm version in production and only install from GitHub when you are deliberately chasing a fix.

Note that the README tags both blocks as `ruby`, which is a long-standing slip in the file. They are npm commands, not Bundler commands, and running them through Ruby tooling will not do what the text suggests.

Cookies in an env file are the whole authentication model

There is no username and password flow in this library. Authentication is two cookies taken from a signed-in TradingView session, and the repository ships a sample file that says exactly which:

SESSION=... # Your sessionid cookie
SIGNATURE=... # Your signature cookie

The file is named `.env.sample`, and the npm scripts wire it into Node: `"example": "node --env-file=.env"` with an `example:dev` variant that runs the same through nodemon. So the intended workflow is to copy the sample, paste your two cookie values in, and run an example file.

This is the design decision with the longest consequences. Those two values are equivalent to being logged in. They are read from the browser's cookie store for a session you authenticated yourself, which means they carry the full authority of that account, including anything your subscription unlocks. `.gitignore` is present in the tree, so the project expects the real `.env` to stay untracked, but that protection only holds if you do not paste cookies into a file named something else.

It also means the features list is partly a statement about subscription tiers. Premium features and replay mode are checked boxes; fake replay mode is explicitly marked as working for the free plan. Anything your account cannot access, the library cannot give you.

What the checkbox list admits and denies

The features section is a markdown checklist, which makes it unusually honest. Checked: premium features, automatic backtesting of many strategies and settings, retrieval of drawings made on your chart, invite-only indicators, unlimited simultaneous indicators, real-time data, TradingView's own technical analysis, replay mode plus fake replay mode for free accounts, and values for a specific date range.

Unchecked, and just as informative: TradingView socket server emulation, interaction with public chats, screener top values, hotlists, and the economic calendar. Those are the surfaces with real abuse potential, so treat the unchecked list as a design boundary rather than a to-do backlog. The README closes the list with a note asking readers to request features, which is an invitation to propose exactly that kind of endpoint.

The stated use cases underneath are trading bots, Discord alerts, hard backtesting, machine learning based indicators, and free replay mode on all timeframes. Read together with the supported timeframes and backadjustment parameter that appeared in the 3.5.0 release, the picture is of a charting-library companion for people who want to compute on data they can already see, not a market data provider.

One caveat belongs here rather than in a footnote: the accuracy of a value returned here is TradingView's accuracy, and the reliability of an indicator reading depends on a subscription and a session that can expire at any time.

The examples folder is the actual documentation

There is no manual, no API reference and no docs site in this repository. The README points at one place: all examples and snippets are in the `./examples` folder, and it asks you to look there and at previously resolved issues before opening a new one. That is the maintainer's stated reason for not writing more documentation, and the examples list shows how much that costs.

Fifteen files are present in the tree. The ones a new user should read in order are `SimpleChart.js` for the minimum working case, `BuiltInIndicator.js` for indicator values, `ReplayMode.js` and `FakeReplayMode.js` for the replay feature the free plan can reach, `Search.js` for symbol resolution, and `Errors.js`, which given the nature of this project is probably the most valuable of the set.

The remainder are more specialised and still runnable: `AllPrivateIndicators.js`, `CustomChartType.js`, `CustomTimeframe.js`, `FromToData.js`, `GetDrawings.js`, `GraphicIndicator.js`, `MultipleSyncFetch.js`, `PinePermManage.js` and `UserLogin.js`. That last one is the entry point to the cookie model, since it is what turns a browser session into the two values your `.env` needs.

Copying a file out of `examples/` and editing it is the intended development loop. The maintainer explicitly says they cannot help with questions that are about JavaScript rather than the library, which is a reasonable boundary for a project with this volume of GitHub issues at 103 open.

Release notes that read like a bug tracker

Three releases are visible, and their bodies tell you what maintenance on a protocol client actually looks like. Version 3.5.2, published 2025-10-05, fixed getting the id of a market in `searchMarketV3`, added websocket error handling for unexpected HTTP errors such as 429, added pagination to `searchMarketV3`, and updated the GitHub Actions node setup.

Version 3.5.1, published 2025-02-22, is almost entirely a stability release: improved test stability, a fix to `getUser` expectations, and an authentication fix. That last item is the informative one. Authentication breaking and being repaired within one version is the expected rhythm for a library that authenticates with cookies against an endpoint it does not control.

Version 3.5.0, published 2024-12-17, added a backadjustment parameter to `session.js`, removed a memory leak, fixed the 'max number of studies per chart' error, updated Vitest, and included a fix for bug 259 from an outside contributor. The memory leak fix is worth noting for anyone running this in a long-lived process.

GitHub reports the last push on 2026-06-23, roughly three months before this repository's most recent activity, with 5122 stars and 910 forks. The gap between the last release in October 2025 and pushes continuing into 2026 suggests work landing on `main` without a tag, so pinning the npm version means pinning to 3.5.2 rather than to whatever is newest.

Editorial conclusion

The library is genuinely good at the two things free data sources are bad at, real-time values for indicators nobody publishes source for, and reading back the drawings you already made on a chart. What it cannot be is a stable contract with a vendor, since it re-implements a private protocol and every authentication change breaks it, which is why 3.5.1 was an authentication fix and 3.5.2 added handling for unexpected HTTP errors such as 429. Read `examples/ReplayMode.js` and `examples/SimpleChart.js` first, keep your `.env` out of version control, and treat any strategy you build on it as one that needs a data source you control.

Frequently asked questions

Official sources

1. Issues
2. Mathieu2301/TradingView-API on GitHub
3. README
4. Releases