TradingView API - Moses Yebei

The Problem

Getting real-time market data from TradingView typically requires either a paid API subscription or scraping HTML pages. TradingView's internal WebSocket protocol is undocumented and changes frequently, making it impractical to reverse-engineer for each project. This library wraps that protocol so developers can pull live prices, indicator values, and chart data without maintaining their own TradingView integration.

What This Does

TradingView-API is a JavaScript/TypeScript client for TradingView's private WebSocket API. It handles authentication (including invite-only indicators), real-time chart subscriptions, technical analysis scans, replay mode, and quote sessions. The src/ directory contains the core: client.js manages the connection lifecycle, src/chart/session.js handles chart data, src/quote/market.js and src/quote/session.js manage quote streams, and src/protocol.js parses/format WebSocket packets. The examples/ folder has 15 runnable snippets covering everything from simple charts to Pine permission management.

This is a fork of Mathieu2301/TradingView-API (4,290 stars upstream), with no additional commits visible in the analysis. The README still points to the upstream author's badges and support links.

How It Is Wired

Execution starts at main.js (24 modules import it, making it the hub with a 0.17 instability score). The entry point exports the Client class and helper functions like getIndicator and getIndicData. From there, control flows into src/client.js, which owns the WebSocket connection and handles onConnected, onLogged, and onError events. src/utils.js provides genAuthCookies — called from 8 places, the widest blast radius in the codebase — and genSessionID, both essential for establishing a session.

The internal call graph shows 65 resolved edges. The critical path is: main.js → src/client.js → src/protocol.js (formatWSPacket/parseWSPacket) → WebSocket. Outbound network calls happen in src/miscRequests.js (16 functions, including fetchScanData and searchMarket) and src/classes/PinePermManager.js. Tests exercise the API heavily: tests/ calls onError 8 times and setMarket 6 times, confirming the test suite drives real behavior.

The module graph has no circular dependencies, which is good. The hub risk is concentrated in main.js — any change there ripples through 24 dependents.

How To Use It

git clone https://github.com/moses-y/TradingView-API
cd TradingView-API
npm install

Configuration lives in .env.sample (copy to .env). Authentication requires TradingView credentials — see examples/UserLogin.js for the login flow. Run any example directly:

node examples/SimpleChart.js

The package's public API is the Client class from main.js. There's no CLI — you write a script that imports the library and subscribes to symbols.

Real-World Use

A trading bot that watches a symbol and alerts on Pine indicator crossovers:

const { Client } = require('./main.js');
const client = new Client();
client.onReady().then(() => {
  const chart = client.createChartSession();
  chart.setMarket('BINANCE:BTCUSDT', { type: 'crypto' });
  chart.setSeries('close');
  chart.onUpdate(data => {
    if (data.close > 50000) console.log('BTC crossed 50k');
  });
});

Code Health & Issues

Static analysis found 2 findings (1 high, 1 medium):

High — Duplicated code blocks: 36 repeated 6-line blocks across 16 files, concentrated in examples/. Extract shared helpers.
Medium — Hub module: main.js has 24 dependents; keep it stable and move volatile logic out.

SDLC observations:

High — No LICENSE file at root; redistribution rights are undefined.
Medium — CI workflow .github/workflows/tests.yml lacks least-privilege permissions, persist-credentials: false, timeout-minutes, and dependency scanning.
Medium — No Dependabot/Renovate configured despite 1,322 dependencies in the lockfile.

The Bottom Line

A functional TradingView client that solves a genuinely hard problem — the WebSocket protocol is undocumented and fragile. The code is reasonably organized with good test coverage (12 test files), but it's an unmaintained fork with no license and duplicated example code. Use it if you need TradingView data without a paid API; expect to maintain the WebSocket layer yourself as TradingView changes their protocol.

What the analyser found

Deployment readiness

5/7

Container image
CI pipeline
Lockfile committed
Test suite
README
License
No committed secrets

Composition

54 files

JavaScript31
TypeScript11
Markdown4
YAML2
JSON2

React

Architecture

Top-level areas of the codebase, sized by module count. Arrows show how many imports cross from one area into another.

graph TD g0["examples<br/>15 modules"] g1["src<br/>13 modules"] g2["tests<br/>11 modules"] g3["(root)<br/>3 modules"] g0 -->|15| g3 g2 -->|9| g3 g3 -->|5| g1 g2 -->|1| g1

Module dependencies

The 10 most depended-upon modules of 42, from static import analysis. Red outline marks a module in an import cycle.

graph LR n0_main["main"] n1_src_utils["utils"] n2_tests_utils["utils"] n3_src_miscRequests["miscRequests"] n4_src_classes_PineIndicator["PineIndicator"] n5_src_classes_BuiltInIndicator["BuiltInIndicator"] n6_src_protocol["protocol"] n7_src_chart_study["study"] n8_src_client["client"] n9_src_chart_session["session"] n0_main --> n3_src_miscRequests n0_main --> n8_src_client n0_main --> n5_src_classes_BuiltInIndicator n0_main --> n4_src_classes_PineIndicator n9_src_chart_session --> n1_src_utils n9_src_chart_session --> n7_src_chart_study n7_src_chart_study --> n1_src_utils n7_src_chart_study --> n6_src_protocol n7_src_chart_study --> n4_src_classes_PineIndicator n7_src_chart_study --> n5_src_classes_BuiltInIndicator n8_src_client --> n3_src_miscRequests n8_src_client --> n6_src_protocol n8_src_client --> n9_src_chart_session n3_src_miscRequests --> n4_src_classes_PineIndicator n3_src_miscRequests --> n1_src_utils

Findings

MediumNo LICENSE file - unclear usage/redistribution rights root

What would stop me shipping this

Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.

high1

medium4

low1

Add a LICENSE; redistribution rights are undefinedhigh

no licence file at the repository root

Fix: Add MIT or Apache-2.0 at the repository root.

Declare least-privilege permissions for GITHUB_TOKENmedium

.github/workflows/tests.yml

1 workflow(s) declare no permissions, 1 of them reference secrets

With no declaration the token inherits the repository default, so any injected step can push commits or mint releases from inside your own CI.

Fix: Add permissions: contents: read at the top of the workflow and widen per job only where needed.

Enable Dependabot or Renovatemedium

1 manifest(s), no update bot configured

Without a bot a published advisory sits unpatched until someone audits by hand, which across 1,322 repositories means never.

Fix: Commit .github/dependabot.yml covering the repo ecosystems plus github-actions.

Gate pull requests on a dependency vulnerability scanmedium

.github/workflows

no dependency scan in CI

This is the one gate that would catch a known-vulnerable package before it reaches a build, and no repository in the sample had it.

Fix: Add dependency-review-action on pull_request, or osv-scanner on push and a schedule.

Set persist-credentials: false on checkoutmedium

.github/workflows/tests.yml

checkout keeps the token, then dependencies are installed

The token stays in .git/config for every later step, so a malicious postinstall script reads a pushable credential without one ever being passed to it.

Fix: Add with: persist-credentials: false, and pass an explicit token only to the step that pushes.

Set timeout-minutes on the workflow jobslow

.github/workflows/tests.yml

1 workflow(s) declare no job timeout

A wedged step runs to the six-hour platform default, which on a two-hourly schedule means three runs overlap behind it.

Fix: Add timeout-minutes with a realistic bound to each job.

Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.