Reaching a Dhan trader’s holdings, positions and order book

A Dhan account is a window onto a CDSL or NSDL demat record plus a live trading session: holdings split into T1 and delivered quantity, open positions that mix intraday with F&O carryforward, an order book, a trade book, and a funds ledger. The store listing puts the user base above a million and says 95% of orders execute under 25 milliseconds — a fast, stateful backend with a lot a downstream system would want to read. The question for an integrator is which of those surfaces is reachable under proper authorization, and how cleanly. Most of it is.

How the data is reached

Two genuinely different routes apply, and for Dhan they are complementary rather than competing.

Consent-based read through the Account Aggregator network

India’s securities holdings are shareable through the RBI Account Aggregator rail. SEBI’s August 2022 circular named the depositories as Financial Information Providers, and both NSDL and CDSL are live as FIPs — meaning equity, ETF and other demat-held instruments tied to a customer’s PAN can be fetched, with that customer’s explicit consent, through a registered AA. For a Dhan user whose securities settle into CDSL or NSDL, this is the durable, regulator-blessed path to holdings and statements. It does not carry live order status, so it is a strong half rather than the whole picture. We set up the FIU-side consent flow and the fetch.

Authorized protocol analysis of the app session

For the live surfaces the AA rail does not reach — open positions, the working order book, the trade book, intraday funds — we map the app’s own authenticated traffic, working against a consenting account you control. This captures the session token model, the per-surface request shapes and the response fields exactly as the app sees them, then we rebuild them as a clean read API. Native in-app export of statements is wired in as a low-effort fallback for anything better served by file pull.

For a build that needs both holdings and live trading state, the protocol route carries the day-to-day reads while the AA consent rail anchors the holdings half on a regulated footing; we reconcile the two into one normalized output rather than treating either as complete on its own.

Read shape we rebuild

Illustrative, not a published contract — field names below mirror what the portfolio surfaces expose to a signed-in user and are confirmed against the live app during the build.

# auth: short-lived session token from consented credentials
POST /session/token
  -> { "accessToken": "<jwt>", "expiresIn": 86400 }

# delivery + T1 split, ISIN-keyed
GET /portfolio/holdings        Header: access-token: <token>
  -> [ { "isin": "INE467B01029", "tradingSymbol": "TCS",
         "exchange": "NSE", "totalQty": 12, "t1Qty": 4,
         "availableQty": 8, "avgCostPrice": 3870.50 } ]

# intraday + F&O carryforward in one list
GET /portfolio/positions
  -> [ { "tradingSymbol": "BANKNIFTY24JUN", "productType": "MARGIN",
         "netQty": -50, "buyAvg": 0, "sellAvg": 511.2,
         "realizedProfit": 0, "unrealizedProfit": 1840.0 } ]

# order book — poll for status transitions
GET /orders
  -> [ { "orderId": "11250...", "status": "TRADED",
         "txnType": "BUY", "qty": 12, "price": 3868.0,
         "orderType": "LIMIT", "ts": "2026-06-26T09:21:44+05:30" } ]

# on 401: refresh token, then retry once with backoff
      

What lands at the end

The output is built around Dhan’s actual surfaces, not a generic broker template:

• An OpenAPI/Swagger spec for the holdings, positions, order-book, trade-book and ledger reads, with the T1-versus-delivered and intraday-versus-carryforward distinctions modeled explicitly.
• A protocol and auth-flow report: the session token lifecycle, refresh behaviour, and the consent-handoff for the AA path.
• Runnable source for the key reads in Python and Node.js, with token refresh and 401 retry handled.
• Automated tests against recorded fixtures so a portal change is caught, not discovered in production.
• Interface documentation, plus consent-record and data-retention guidance fit for a SEBI-regulated holding.

Consent and the SEBI / RBI footing

The dependable basis here is the account holder’s own authorization. On the AA path that authorization is formalized: a registered Account Aggregator brokers a time-boxed, scoped, revocable consent between the depository (FIP) and the system reading the data (FIU), and nothing moves without it. We treat consent expiry and revocation as first-class — the fetch checks the consent artefact before each pull and stops cleanly when it lapses. On the protocol path the equivalent is the customer’s written go-ahead to act on their own account, with access arranged with you during onboarding against a consenting login. Either way we log what was read and when, minimize to the fields a use case actually needs, and work under NDA where the data is sensitive. SEBI governs the securities activity; the RBI framework governs the data rail.

Things we account for on this build

A few Dhan specifics shape how we design the integration:

• We model the T1 / delivered / available quantity split on holdings so a downstream balance does not double-count shares still in settlement — getting this wrong quietly corrupts any position-value calculation.
• We design the positions read to keep intraday and F&O carryforward separated by product type, because their margin and square-off semantics differ and collapsing them loses meaning.
• We tune the order-book poll cadence and add idempotent reconciliation, so we observe Dhan’s fast order flow without sitting in the execution path or missing a status transition.
• We wrap a fixture-backed check around the session surfaces so that when the app’s front end shifts, the test fails first and the maintenance pass is scheduled before data goes stale.

Where integrators take this

• A portfolio tracker that consolidates a user’s Dhan demat holdings with accounts at other brokers into one net-worth view via the AA rail.
• A tax or P&L tool that pulls the trade book at year end to compute realized gains across equity and F&O.
• An advisory dashboard syncing client positions and order status on a polling cadence for monitoring, not execution.
• A reconciliation job matching the funds ledger against an internal book of record.

Interface evidence

Store screenshots used while mapping the surfaces — click to enlarge.

Apps in the same data neighbourhood

Other Indian broking and demat apps hold the same shape of record, which is why a single normalized integration usually targets several at once:

• Zerodha Kite — large discount broker; holdings, positions and order book behind a demat account.
• Groww — stocks and mutual funds; portfolio and SIP records per user.
• Upstox — equity, F&O and currency with live positions and order history.
• Angel One — full-service broking with holdings, ledger and research surfaces.
• Fyers — trader-focused platform with detailed positions and order data.
• Rupeezy — leverage-friendly broker holding the same demat-linked records.
• ICICI Direct — bank-linked broking with holdings and statement data.
• SAMCO — discount broker with portfolio and order-book surfaces.

Questions integrators ask

Can a Dhan user’s demat holdings be reached through the Account Aggregator network?

Securities holdings sit in a CDSL or NSDL demat account, and SEBI has named both depositories as Financial Information Providers in the RBI Account Aggregator framework. With the account holder’s consent passed through a registered AA, equity and ETF holdings tied to a Dhan account can be read that way. We build the consent flow, the fetch, and the normalization.

Does the work cover F&O positions and the order/trade book, not only delivery holdings?

Yes. Dhan exposes intraday and F&O carryforward positions, an order book and a trade book to the signed-in user, with T1 versus delivered quantities split out on holdings. Where the AA route does not carry a live surface, we map it from the app’s own session traffic under the account holder’s authorization and reconcile both into one schema.

Which regulator and registration sit behind Dhan?

Per its store listing, trades clear through a SEBI-registered broking member (Raise Securities Pvt. Ltd., SEBI registration INZ000006031 as stated there) across NSE, BSE and MCX. SEBI governs the securities side; the RBI Account Aggregator framework governs the consent rail for sharing the underlying holdings data.

How do you handle the sub-25-millisecond order flow Dhan advertises?

We do not sit in the execution path. The integration reads state — holdings, positions, order status, ledger — on a polling or event cadence you choose, so the broker’s order latency is untouched. For near-real-time order status we tune the poll interval and add idempotent reconciliation rather than racing the matching engine.

Working with us

You give us the app name and what you need out of its data; access, consenting accounts and any compliance paperwork are arranged with you as the project runs. Source delivery for this build starts at $300 — runnable code for the holdings, positions, order-book and ledger reads plus the OpenAPI spec and tests, billed only after it is in your hands and working. If you would rather not host anything, call our endpoints and pay per call with nothing upfront. The cycle runs one to two weeks either way. Start at /contact.html.

How this was put together

Surfaces were mapped from Dhan’s own support and portfolio documentation and its store listing; the consent rail was checked against SEBI’s depository-FIP circular and the depositories’ live FIP pages, on 26 June 2026.

• Dhan support — orders and positions
• SEBI circular — depositories as FIP in the AA framework
• CDSL — Financial Information Provider
• Dhan store listing (App Store)

Mapped by the OpenBanking Studio integration desk · 26 June 2026.