Building with the API? Open the developer docs
Finmagine API & MCP — free tier to test • Pro/Max for full access • REST + MCP
Master the Trader Workflow through a complete learning overview and interactive flashcards
Guide #10 covered what each trader-scan type means. This final guide covers the composition pattern — calling the same trader-scan endpoint 3 times with different scan_type values and intersecting the results, the same "cross-reference, don't auto-chain" pattern as the Momentum Setup Workflow, applied to technical scans instead of market-wide signals.
Click any card to reveal the answer. Use the search box to find a specific topic.
Unlike most workflows in this series, the Trader Workflow isn't multiple different endpoints — it's one endpoint, called 3 times, with a different scan_type parameter each time:
Each call returns its own independently-ranked list of symbols. The actual "workflow" is what you do after all 3 calls return: intersect the 3 symbol sets. A stock appearing in all 3 lists simultaneously has cleared three genuinely different technical bars at once — not just one.
Of the 7 US scan types (or 8 India scan types), these 3 answer three genuinely different, complementary questions:
| Scan | Question it answers |
|---|---|
| Stage 2 | "Is this stock already in a confirmed uptrend?" — the broader structural context |
| Near High | "Is it close enough to a meaningful breakout level right now?" — proximity to the actual trigger point |
| BRS (Breakout Readiness Score) | "Is it showing the specific pre-breakout compression pattern, not just drifting near a high?" — the "coiled spring" quality |
VCP and High Volume are deliberately left out of this particular combination — not because they're less valuable, but because Stage 2 + Near High + BRS is the tightest 3-scan combination for "about to break out," while VCP and High Volume answer somewhat different questions (a specific base pattern, and a possible institutional-interest signal, respectively) that don't compose as cleanly into the same "is this about to move" question.
Each of the 3 calls returns a stocks array. The workflow itself is a straightforward set intersection on the symbol field:
Because each scan is capped at up to 50 results (the platform-wide limit clamp), the intersection is working over 3 relatively small, already-curated lists — not a full-universe join — which keeps this a fast, cheap client-side operation.
Guide #10 covered stage2nh — a scan type that's already precomputed as the Stage 2 + Near High combination. If you don't need each of the two conditions as a separately inspectable list, you can skip one call:
Then intersect just these 2 result sets instead of 3. This trades a small amount of intermediate visibility (you no longer see the Stage 2-only and Near High-only lists separately) for one fewer round trip.
Both markets support this exact composition pattern — one endpoint, multiple scan_type calls, manual intersection — but the details underneath differ in ways worth knowing before you build a market-agnostic client.
| India | US | |
|---|---|---|
| Endpoint | GET /market/trader-scan | GET /us/market/trader-scan |
| Scan types available | 8 — allThree, stage2NearHigh, vcp, highVol, stage2, brs, volume, ipo | 7 — all, stage2nh, stage2, nearHigh, highVol, brs, vcp |
| Naming convention | Mixed case, e.g. stage2NearHigh | camelCase, e.g. stage2nh |
| Source table | trader_scan_results | us_trader_scan_results |
| Cron schedule | 30 12 * * 1-5 IST (weekdays) | 30 22 * * 1-5 UTC (weekdays) |
stage2NearHigh and volume/ipo (with no US equivalent for the latter two); US uses stage2nh and has no volume or ipo scan type at all. A client that hardcodes one market's scan_type strings and reuses them unmodified against the other market's endpoint will get a 400.
India's handler docblock states this data is gated deliberately as "a product decision (2026-07-28)" — the underlying internal endpoint (api/trader-picks.php) is itself public, but the versioned API adds a premium gate on top as a considered choice, not a technical necessity. The US handler's reasoning runs the other direction: the underlying web page is already gated behind login + premium, so the versioned API's api_pro requirement simply matches an existing restriction rather than introducing a new one. Same tier gate on both, different history behind why.
This is guide 12 of 12. Across the series, you've gone from "what does an AI agent even fetch first" (llms.txt) through the full contract (openapi.json), zero-code tooling (the two Explorers), the two flagship LLM systems (Research Presets and the Investment Committee), the file that ties it all into ready-made chains (agent-recipes.json), and finally the raw endpoints and composition patterns behind US technical research.
Every guide in this series was written against the real, live code — actual thresholds, actual field names, actual quota numbers, actual bugs that were found and fixed — not simplified or invented for the sake of a tidy narrative. If something here ever stops matching what the live API actually does, that's a documentation bug worth reporting, not an acceptable drift.
Finmagine gives you 30+ computed financial ratios, sector benchmarks, FII/DII flows, the Finmagine Score, and AI-powered analysis — all in one place.