Getting a Groww account's records into your own systems

One Groww login sits on top of four separate record systems presented as a single portfolio: a demat account for equities and ETFs, a mutual-fund folio book, a Futures & Options position sheet, and an MCX commodity ledger for gold, silver, crude and the rest. The app also describes itself as India's largest stock broker by active customers, citing NSE data dated October 2025 on its own store listing. For anyone building a portfolio tracker, a tax tool, an advisory dashboard or a reconciliation pipeline, the value is in those per-user ledgers — and India already runs a regulated consent rail that carries part of them.

The short version: the holdings and mutual-fund side can move over the Account Aggregator rail with the user's consent, which is durable and regulated. The trading side — the live order book, F&O and commodity positions, intraday state — is not carried by that schema, so it comes from an authorized integration against the account holder's own client. Below is how each piece is reached and what we hand over.

Reaching a Groww account's records

The holdings and mutual-fund side of a Groww account can move over India's Account Aggregator framework. SEBI, in its August 2022 circular, allowed the depositories to act as Financial Information Providers, and NSDL is live in that role. Under this route a Financial Information User requests data, the user approves the consent on their Account Aggregator, and demat holdings plus mutual-fund units flow back in a standardized schema. It is consent-scoped, revocable and survives app updates, because it does not depend on the app's front end at all. Setting up the Financial Information User side — onboarding through a licensed Account Aggregator, drafting the consent template and purpose code — is work we do with you as the project starts.

Authorized interface integration covers what the consent rail does not. Working against the account holder's own login, we map the auth and token-refresh chain the client uses, then read the order and trade book, F&O and commodity positions, margin and the portfolio-analytics fields. This reaches everything a user sees in the app, at the freshness the app has, and it is the route for live and intraday state. It carries a maintenance cost, since a front-end change can move a field; we account for that rather than pretend it away. A lighter variant is user-consented session access, driven by the person logging in themselves when a standing integration is not wanted.

Native export sits underneath both: consolidated account statements from the depository, contract notes, mutual-fund statements and profit-and-loss files. Low effort, low granularity, batch-only — useful for periodic backfill or a one-off migration rather than a running feed. For most Groww builds I would anchor the holdings and mutual-fund picture on the Account Aggregator consent flow, because it is regulated and NSDL already publishes it, and cover the order book, F&O and commodity positions with the authorized integration, since those live outside what the consent schema carries. The two together give both a durable statement of record and the live trading state.

Consent, SEBI and the Account Aggregator rail

Groww Invest Tech is a SEBI-registered broker and a CDSL depository participant, per its own store listing. That matters for consent design. The demat holdings a user sees in the app sit with the depository, and the depository — not the broker — is the Financial Information Provider on the Account Aggregator rail. So a consented pull of holdings is scoped against NSDL or CDSL, with a defined data range, a purpose code and a validity window; the user can revoke it at any time from their Account Aggregator. On the privacy side, India's Digital Personal Data Protection Act 2023, whose operating Rules were notified in November 2025, treats consent as the primary lawful basis and requires that data be used only for the stated purpose and erased when consent is withdrawn. We build to that: consent records and logs are kept, the data set is minimized to what the use case needs, and an NDA covers the engagement where the client wants one. Access is authorized, documented and consent-backed throughout — no credential-defeating anywhere in the method.

What sits in a Groww account

Deliverables for a Groww integration

The output is a working integration, not a report. For a Groww build that means:

• An OpenAPI/Swagger specification for the normalized endpoints — holdings, folios, orders, positions, margin — with the field names as they resolve for this account.
• A protocol and auth-flow write-up: the token and refresh chain, session handling and pagination as observed while building, plus the Account Aggregator consent artifact for the holdings route.
• Runnable source for the key calls in Python and Node.js, structured as a typed client rather than throwaway scripts.
• Automated tests — contract tests against recorded fixtures so a field change is caught rather than shipped silently.
• A normalized schema that folds the Account Aggregator financial-information types and the app-side fields into one model, so an ISIN reads the same whether it arrived by consent or by integration.
• Interface documentation and data-retention guidance aligned to the consent scope and the DPDP erasure rule.

A holdings-and-orders pull, sketched

# Illustrative only. Field names are confirmed against the account during the build.

# 1. Authorized session against the account holder's own Groww login.
sess = GrowwClient(auth=token)             # token/refresh chain documented in the auth-flow report

# 2. Equity holdings (NSE/BSE delivery), one row per ISIN.
holdings = sess.get("/portfolio/holdings")
# -> [{ "isin": "INE...01", "tradingsymbol": "...", "quantity": 40,
#       "avg_price": 812.5, "ltp": 947.0 }]   # normalized field names

for h in holdings:
    h["pnl"] = round((h["ltp"] - h["avg_price"]) * h["quantity"], 2)

# 3. Order/trade book across segments.
orders = sess.get("/orders", params={"segment": ["EQ", "FNO", "COMM"],
                                      "from": "2026-04-01"})

# 4. Mutual-fund folios: native + imported (CAS), de-duplicated on (folio, isin).
folios = dedupe(sess.get("/mf/holdings"), key=("folio", "isin"))

# Errors: 401 -> refresh token, retry once; 429 -> backoff; partial page -> paginate on "cursor".

The holdings shape above is also what the Account Aggregator route returns for the demat side, minus the live price, which is why the normalized model keeps a single holdings type fed by either source.

Groww-specific engineering calls

Mutual funds arrive by two paths that have to be reconciled. Groww lets a user import and redeem external funds alongside folios opened inside the app, and a consolidated account statement can list the same ISIN that a native folio already holds. We de-duplicate on the folio-and-ISIN key so a merged portfolio does not count the same units twice.

Corporate actions move numbers between the holdings snapshot and the trade book. A split or bonus changes quantity and average cost without a matching trade, so a naive P&L that reads only the order book drifts. We add a reconciliation pass keyed to corporate-action dates so historical returns stay consistent across the event.

Consent and expiry are designed in, not bolted on. The Account Aggregator consent carries a validity window and a data range; we build the sync so it refreshes before it lapses and registers the purpose code that keeps the pull inside the consented scope. For the integration route, F&O and MCX instruments roll on expiry, so we map the instrument master and handle the roll, and keep a small replay harness so a front-end change surfaces as a failing test rather than a bad number in production.

Screens we mapped against

Store screenshots from the listing, used while tracing which surface holds which record.

Pricing and how delivery works

Delivery runs one to two weeks from the point we agree the record set. Source-code delivery starts at $300: you get the runnable Python and Node.js client, the OpenAPI specification, the tests and the interface documentation, and you pay after it is delivered and you have confirmed it works against the account. The other model is our hosted endpoints — you call them and pay per call, with nothing upfront and no source to maintain. Which one fits depends on whether you want to run the client yourself or just consume the data. Tell us the app and what you need out of it, and we take it from there: start on the contact page.

Other Indian broking and investing apps

Same category, so the same integration model applies — a unified view usually spans several of these.

• Zerodha (Kite) — India's largest discount broker; demat holdings, order book and Coin mutual-fund folios behind one login.
• Upstox — discount broker with equity, F&O and mutual-fund holdings and a clear positions model.
• Angel One — full-stack broker holding equity, commodity and mutual-fund records plus advisory data.
• Dhan — trading-focused broker with holdings, positions and TradingView-linked order history.
• Paytm Money — investment app holding stocks, mutual-fund folios and NPS records.
• 5paisa — discount broker with equity, F&O and mutual-fund holdings under a flat-fee model.
• ICICI Direct — full-service broker holding demat, mutual-fund and fixed-income records.
• Fyers — trader-oriented broker exposing positions, holdings and order history.
• INDmoney — aggregator app holding mutual-fund, Indian-equity and US-stock records across linked accounts.

What we checked, and where

This mapping was put together from Groww's Play Store listing (registrations, segments and the instrument set), the SEBI circular that brought depositories into the Account Aggregator framework as Financial Information Providers, CDSL's own FIP page and Sahamati's list of financial-information types on the rail, and the text of the DPDP Act 2023. Reviewed on 1 July 2026 by the OpenBanking Studio integration desk.

• SEBI — depositories as Financial Information Providers in the AA framework (Aug 2022)
• CDSL — Financial Information Provider (demat data on the AA rail)
• Sahamati — financial-information types available on Account Aggregator
• MeitY — Digital Personal Data Protection Act, 2023 (full text)
• Google Play — Groww Stock, Mutual Fund, Gold listing

Questions integrators ask about Groww

Does the Account Aggregator rail cover a user's F&O and commodity positions, or only holdings?

The SEBI Financial Information Provider schema on the Account Aggregator rail carries demat holdings — equities, bonds, ETFs — and mutual-fund holdings. Live F&O, MCX commodity and intraday order data sit outside that schema, so those come from the authorized protocol integration against the account holder's own Groww client.

Groww lets users import external mutual funds. Do those show up in the pull too?

Yes. Imported folios sourced from a consolidated account statement and folios native to Groww can carry the same ISIN, so we de-duplicate on the folio-plus-ISIN key in the normalized model, otherwise a consolidated view double-counts the units.

Which entity actually holds the data, for consent purposes?

Groww Invest Tech Pvt Ltd is the SEBI-registered broker (registration INZ000301838 per its Play Store listing) and a CDSL depository participant. Demat holdings sit with the depository, which is the Financial Information Provider on the Account Aggregator rail, so consent scope and purpose codes are set against that.

Can you keep a Groww portfolio in sync, not just pull it once?

Yes. We design the sync around the Account Aggregator consent validity window so the feed does not silently expire, and add a reconciliation pass for corporate actions such as splits and bonuses so a running mirror stays accurate. Delivery of the working integration is one to two weeks.