How to Automate an Indian Stock Watchlist in 2026

Key takeaways

• Use REST to recover recent events before opening a WebSocket for new ones.
• Store the exchange, symbol, International Securities Identification Number (ISIN), owner, and alert rules for every company.
• Convert every incoming event into one consistent record and reject duplicates before sending alerts.
• Apply clear routing rules before adding AI, and keep the original source linked in every important alert.
• Use Drishti for company-event monitoring, a broker API for account-linked orders, and a licensed data vendor for full-depth or tick-level feeds.

Quick answer: which tool should you use?

Most investors and builders need more than one tool because price alerts, company disclosures, order execution, and tick data are different jobs.

Consider Drishti when the main job is finding out what changed at a company and retaining the source document. Use TradingView or broker alerts for price and technical conditions. Add a broker API only when the workflow needs account-linked execution. The Indian stock market API comparison explains the feed and licensing choices.

The watchlist monitoring loop

Watchlist → Backfill → Stream → Rules → Delivery → Audit log
symbols     REST       WebSocket  clean + route  alerts    sources + review

A reliable monitor recovers recent events, streams new ones, applies repeatable rules, delivers useful alerts, and keeps an audit trail.

If a price threshold goes straight to Slack, the recipient gets an alert with no context. Each message should answer four questions: what happened, which holding is affected, where is the source, and who reviews it?

Why an Indian stock watchlist is an event problem

A price watchlist can tell you that a stock moved. A filing may tell you why.

Indian listed companies make event-based and periodic disclosures to recognised stock exchanges. SEBI’s 2026 Listing Obligations and Disclosure Requirements (LODR) master circular consolidates the disclosure framework for listed entities. BSE’s filing guidance also requires corporate announcements to be submitted in machine-readable, searchable PDF format through its specified electronic filing platform.

So filings belong beside prices in the watchlist. Depending on the portfolio, you may want to track:

• corporate announcements and attached exchange documents;
• quarterly and annual results;
• board-meeting and corporate-action events;
• earnings conference calls and transcripts when available;
• company and market news;
• 52-week highs or lows, price changes, unusual volume, and relative-volume alerts;
• block deals relevant to a holding or research universe.

Choose the data source by the job. Brokers handle account-linked orders. Licensed exchange-data vendors cover depth and ticks. Event-intelligence APIs collect filings, earnings, commentary, news, and alert signals. The Indian stock market API comparison maps those boundaries in detail.

Step 1: define a watchlist contract

A single ticker column is too fragile for this job. Give every watchlist entry enough information to survive a symbol change and reach the right person.

A useful watchlist record includes the exchange, symbol, and International Securities Identification Number (ISIN) when the source provides it:

{
  "symbol": "RELIANCE",
  "exchange": "NSE",
  "isin": "INE002A01018",
  "owner": "energy-desk",
  "priority": "high",
  "eventTypes": ["announcements", "earnings", "news", "concalls", "alerts"],
  "channels": ["research-dashboard", "slack"]
}

Use the exchange and a stable security identifier where your source provides one. Symbols change. The same issuer may trade on NSE and BSE. Derivatives need expiry-aware identifiers. Keep those mappings outside the alert rules so a renamed symbol cannot quietly stop the feed.

The owner field prevents a second problem: every alert reaching everyone. Assign each company or strategy to a desk, analyst, portfolio, or product workflow before you switch notifications on.

Step 2: backfill before you start streaming

A WebSocket starts with the next event. Your analyst also needs the events that arrived before the connection opened, so fetch a short history first.

For each company, retrieve the recent records your alert rules will need. With Drishti, the relevant REST products include announcements, earnings, news, conference calls, block deals, and alerts. The Drishti API documentation lists the available product areas and authentication contract.

Store the provider’s record ID, source timestamp, symbol, category, headline or summary, attachment URL, and the time your system received it. When the socket reconnects, those fields let the worker recognise records it has already seen.

A practical startup sequence is:

1. Load and validate the watchlist.
2. Fetch the previous one to seven days of relevant events.
3. Save stable IDs and source timestamps.
4. Run the records through the same prioritization rules used for live events.
5. Open the WebSocket only after the backfill checkpoint succeeds.

Step 3: subscribe to the events you need

Drishti’s official WebSocket reference documents one connection with separate subscriptions for news, block-deals, announcements, earnings, concalls, and alerts. The managed SDK reconnects and replays subscriptions. If you use a raw socket, your application must subscribe again after every reconnect.

Here is a small TypeScript subscriber for announcement events:

import { DrishtiClient } from "drishti-sdk"

const symbols = ["RELIANCE", "TCS", "INFY"]
const client = new DrishtiClient({
  apiKey: process.env.DRISHTI_API_KEY!,
})

const ws = client.websocket({
  onAnnouncements: async (announcement) => {
    await eventQueue.publish({
      channel: "announcements",
      record: announcement,
    })
  },
})

await ws.subscribe({
  product: "announcements",
  symbols,
  detailed: true,
})

Keep the API key on your server. In the event handler, validate the envelope, add the job to a queue, and return. Parse large attachments, call language models, and send notifications from a background worker. The WebSocket setup guide covers the connection details.

Step 4: deduplicate and enrich every event

Retries happen. Companies also amend disclosures. Your deduplication logic needs to tell those two cases apart.

Prefer the upstream record ID when it represents a stable event. Where that is not enough, construct a business key from fields such as provider, symbol, category, source date, and source URL. Store the original payload alongside your normalized record so an analyst can audit how the alert was produced.

Add your internal context in separate fields:

• map the event to the watchlist owner and portfolio;
• attach the original exchange filing or source URL;
• record whether the issuer appears on both NSE and BSE;
• add internal tags such as results, fund-raise, management-change, or volume-spike;
• keep machine-generated summaries separate from source text.

Treat the summary as a shortcut to the source. Keep the source document linked in every material alert.

Step 5: write the rules before adding AI

Start with rules you can read and test. An analyst should be able to explain exactly why an alert landed in a high-priority queue.

Once the routing works, an AI agent can classify an event, extract the change, compare it with earlier company context, or draft questions for an analyst. Pass the source into that step and require the output to link back to it. If the model is unsure, the alert should say so.

Drishti’s Model Context Protocol (MCP) integration supports conversational research by an analyst or agent. REST and WebSockets support servers that receive events, run scheduled backfills, and maintain long-running monitors.

Step 6: send alerts that are useful on first read

A good alert is short but complete:

RELIANCE — Board meeting outcome
Event: Corporate announcement
Published: 2026-09-01 14:32 IST
Why routed: High-priority holding; board decision rule
Source: [Open exchange filing]
Owner: energy-desk
Status: Unreviewed

Send the company, event type, source time, routing reason, source link, owner, and review state. A headline or sentiment label alone leaves the analyst hunting for context.

Reliability checklist for production monitoring

Before relying on the watchlist, check these controls:

• Replay subscriptions after a dropped connection.
• Save a backfill checkpoint so downtime does not create a blind spot.
• Make repeated processing safe: the same event must not create a second alert.
• Put failed parsing and delivery jobs in a visible retry queue.
• Keep the source link on every material alert.
• Store source, received, and displayed timestamps separately.
• Record the rule version that routed each alert.
• Keep research conclusions and investment decisions with the responsible person.
• Store API keys on the server and rotate an exposed key.
• Measure event lag, reconnects, queue age, delivery failures, and suppressed duplicates.

The alerts API reference covers the REST endpoint for dashboards and recovery jobs, plus the WebSocket option for new alerts.

A sensible first version

Start with announcements for ten companies. Backfill yesterday’s records, open the stream, remove duplicates, and send each accepted event to one review queue. Run that version for a week.

The review log will show you what to add next. If analysts keep opening results filings, add earnings. If they ignore routine notices, tighten that rule. Add news, conference calls, prices, and model-generated summaries only when the existing alerts are reaching the right person with the right source.

Frequently asked questions

Can I automate an NSE and BSE watchlist with one API?

Yes, if the provider covers your required events and identifiers on both exchanges. Check announcements, earnings, news, prices, history, depth, and execution separately. A vendor that advertises “NSE and BSE data” may cover only some of them. Drishti focuses on structured event intelligence; exchange feeds, authorised vendors, and brokers cover the other parts of the stack.

Should I poll an API or use WebSockets?

Most monitors need both. REST repairs the state after downtime; WebSockets reduce the delay for new events.

Do I need AI for watchlist monitoring?

No. Get event collection, duplicate handling, routing, and source links working first. AI can then classify events, write summaries, compare disclosures, or prepare questions. The filing and the analyst remain the authority.

Is Drishti a broker or a full-market tick feed?

No. Drishti provides structured Indian-market intelligence through APIs, WebSockets, SDKs, OpenAPI, and MCP. Use a broker API for account-linked orders. For full depth or tick-level data, use an exchange feed or authorised market-data vendor.

Build the first working monitor

Pick ten symbols. Subscribe to announcements. Route every accepted event to one review queue. The WebSocket setup guide has the connection steps; add REST backfills after the first stream is working.