Block Deals Data for India: A Developer's Guide
Drishti now provides structured block deals data for India through REST and WebSockets. You can fetch NSE and BSE records, filter them by symbol, exchange, or date, and put the same item shape into a screener, activity feed, or alerting pipeline.
The new GET /v1/block-deals endpoint returns the fields an application needs: a stable record ID, symbol, company, exchange, trade value in crores, number of shares, price, and trade timestamp when available. It costs one credit per returned item and supports pages of up to 50 records.
This guide covers the contract, working requests, streaming option, and the production decisions that still belong in your application.
What the block deals API returns
The endpoint gives you normalized block-trade prints from NSE and BSE. It does not return an upstream news headline or ask you to parse a human-written story before using the trade.
| Field | Meaning | Application note |
|---|---|---|
id | Stable record identifier | Use this as the first deduplication key |
symbol | Exchange symbol | Normalize case before matching a watchlist |
company | Company name | Display it, but do not use the name as an identity key |
exchange | NSE or BSE | Preserve it when the same security appears on both exchanges |
trade_value_cr | Trade value in ₹ crore | Store as a decimal; do not reconstruct it from formatted text |
shares | Number of shares | Keep as a number and expect large values |
price | Traded price per share | Retain the provider value without rounding it for storage |
date | Trade timestamp when available | Parse as an instant and display it in the user's time zone |
The response envelope is:
{
"data": [
{
"id": "6a7abf1020b97fd270eb7c7a",
"symbol": "RECLTD",
"company": "REC Limited",
"exchange": "NSE",
"trade_value_cr": 24.86,
"shares": 725692,
"price": 342.6,
"date": "2026-08-11T06:19:58.998000+00:00"
}
],
"has_next": false
}
That record is a documented example of the payload shape, not a promise that every response has the same values. Treat nullable or missing fields as missing. Do not substitute zero for an unknown price, quantity, value, or timestamp.
Why block deal data needs its own pipeline
A block deal is not just any large print found in a normal-market trade feed. SEBI's October 2025 review of the block deal framework sets a minimum order size of ₹25 crore for trades executed in the block-deal windows. It also requires every executed trade to result in delivery and requires exchanges to disseminate details such as the scrip, client, quantity, side, and price on the same day after market hours.
NSE Clearing's block deals settlement page says these trades use the BL series and settle on a T+1 rolling basis. NSE and BSE also publish large-deal records through their official NSE block and bulk deal archive and BSE bulk and block deal report.
Those rules explain why a separate data product is useful. Your application should consume the classified record and its exchange, not guess whether a normal-market trade qualifies from value alone.
They also explain an important boundary: a block deal record proves that a disclosed trade occurred. It does not prove why the parties traded, whether a position is new, or what the price will do next. Keep those interpretations out of the ingestion layer.
Fetch block deals by symbol, exchange, and date
Authenticate with X-API-Key and pass only the filters you need. This request fetches the first 20 NSE records for two symbols:
curl -G "https://developers.manasija.in/v1/block-deals" \
-H "Accept: application/json" \
-H "X-API-Key: $DRISHTI_API_KEY" \
--data-urlencode "symbols=RECLTD,NAUKRI" \
--data-urlencode "exchange=NSE" \
--data-urlencode "limit=20"
Available query parameters are deliberately small:
| Parameter | Use |
|---|---|
symbols | Comma-separated symbols or repeated parameters; maximum 20 |
exchange | NSE, BSE, or NSE/BSE |
from | Inclusive ISO date or datetime lower bound |
to | Inclusive ISO date or datetime upper bound |
page | Page number, default 1 |
limit | Page size, default 20, maximum 50 |
For a daily ingestion job, use explicit from and to values and continue while has_next is true. Save the raw response before transforming it. If the job retries, upsert by id so the same trade does not create a second activity item.
The official SDKs expose the same operation. In TypeScript:
const blockDeals = await client.getBlockDeals({
symbols: ["RECLTD", "NAUKRI"],
exchange: "NSE",
limit: 20,
})
And in Python:
block_deals = client.get_block_deals(
symbols=["RECLTD", "NAUKRI"], exchange="NSE", limit=20,
)
Check the current TypeScript SDK guide or API reference before pinning method signatures in generated code. The REST contract is the source of truth for filters and response fields.
Model the record before you build the interface
Give the normalized item its own type at the boundary of your application. This keeps transport code, storage, and UI formatting from quietly disagreeing about units or nullable fields.
type BlockDealItem = {
id: string
symbol: string
company: string
exchange: "NSE" | "BSE"
trade_value_cr: number
shares: number
price: number
date?: string | null
}
Validate the incoming object before you enqueue it. Reject a record with no id; quarantine a record with an unknown exchange; and keep an absent date as null. Validation failures belong in a dead-letter log with enough context to replay them after the parser changes.
Keep provider units in the storage schema. A column named trade_value_cr is harder to misuse than a generic value. If another service needs rupees, convert at that boundary and name the derived field clearly. The same principle applies to the timestamp: store the original value and a parsed UTC instant instead of replacing the source text.
For a cross-exchange company view, do not join records by company-name text. Resolve the exchange and symbol through your security master, then attach your internal security ID as enrichment. That lets the original payload remain auditable when a symbol or company name changes later.
Stream block deal updates over WebSockets
Polling is appropriate for backfills and reconciliation. For a watchlist that should receive new supported records without repeatedly fetching a page, subscribe to the block-deals WebSocket product.
Send one subscription message for the product:
{
"op": "subscribe",
"product": "block-deals",
"symbols": ["RECLTD", "NAUKRI"]
}
Each delivery uses a small envelope, and data mirrors the REST BlockDealItem shape:
{
"channel": "block-deals",
"data": {
"id": "6a7abf1020b97fd270eb7c7a",
"symbol": "RECLTD",
"company": "REC Limited",
"exchange": "NSE",
"trade_value_cr": 24.86,
"shares": 725692,
"price": 342.6,
"date": "2026-08-11T06:19:58.998000+00:00"
}
}
A symbol-filtered subscription works for watchlists. An empty symbol list requests the full feed and requires the relevant Scale entitlement. WebSocket access is evaluated separately from REST access, so a key that can call the endpoint may still receive a 403 at connection or subscription time.
Follow the WebSocket guide for authentication, acknowledgements, reconnection, and delivery semantics. Reconnects can replay or overlap work around a connection boundary, so the consumer should still deduplicate by record ID.
Build a reliable block-deal monitor
The API removes exchange-specific parsing from the first step. It does not remove application design. A production monitor still needs a repeatable path from ingestion to display.
REST backfill -----------+
|
WebSocket subscription --+--> validate --> deduplicate --> store --> notify
| |
+--> dead-letter log +--> reconcile
Use these rules as a starting point:
- Store the raw item. Keep the provider record and ingestion timestamp before enrichment.
- Deduplicate by
id. Add a database uniqueness constraint, not only an in-memory check. - Preserve the exchange. NSE and BSE are part of the record's identity and audit trail.
- Use decimal types for money. Format rupees and crores only at the presentation layer.
- Keep timestamps unambiguous. Store the supplied instant, then render it in Asia/Kolkata or the user's selected zone.
- Separate facts from interpretation. The item can trigger review; it should not automatically label a trade bullish, bearish, or institutional.
- Reconcile the stream. Run a scheduled REST fetch for the same interval and upsert anything the live consumer missed.
- Keep keys server-side. Never put an API key in browser code, a public repository, screenshots, or logs.
For alerts, evaluate rules after persistence. That lets a retry find the existing record before it sends another email, Slack message, or webhook. A stable notification key such as {rule_id}:{block_deal_id} makes the final step idempotent too.
What you can build with the new data
The compact contract supports several useful products without a custom scraper:
- A watchlist activity feed filtered to the symbols a user follows
- A daily NSE and BSE block-deal digest grouped by company
- A historical screen ordered by trade value or filtered to a date range
- A research timeline that places block deals beside announcements and earnings
- A server-side alert when a matching record arrives over WebSockets
Do not turn the feed into an automated investment conclusion. A disclosed trade is evidence of a transaction, not evidence of motive or future return. If your interface adds commentary, label it separately and preserve the underlying fields so a user can inspect what actually happened.
Start with one request
Call the block deals API reference with one or two symbols, store the returned items unchanged, and add a unique constraint on id. Once the backfill is repeatable, connect the WebSocket stream and reconcile it against REST.
You can start with the Drishti Sandbox. The first useful milestone is not a complicated dashboard. It is a small pipeline that can ingest the same block deal twice and still produce one stored record and one notification.
Frequently asked questions
Does the endpoint include buyer and seller names?
The current public BlockDealItem contract does not list buyer name, seller name, or trade side. Build against the documented fields rather than assuming every field visible in an exchange report is present in the API.
Should I use REST or WebSockets for block deals?
Use REST for historical filters, backfills, scheduled digests, and reconciliation. Use WebSockets for supported near-live watchlist delivery. A reliable production system can use both: the stream for prompt processing and REST to repair gaps.
Are block deals and bulk deals interchangeable?
No. They are separate exchange classifications. This endpoint is specifically for block deals, even though exchange websites may place block and bulk reports on the same page. Do not relabel a record or infer one classification from the other.
