Getting holdings, orders and IPO records out of Upstox

A consenting Upstox account exposes more than a portfolio screen: ISIN-wise equity and ETF holdings, a funds ledger, the full order and trade book, mutual-fund units with their SIP schedule, fixed-income and SGB positions, and a record of every IPO application with its allotment result. Most of that securities data is reachable through a regulated consent channel in India, because the depository that backs the demat account — CDSL or NSDL — sits inside the country's consent framework. The broker-specific layer (live order state, GTT and basket orders, IPO bid status) is read separately, under the account holder's authorization. This brief maps both, names the route we would take, and says what lands in your repository.

What an Upstox account actually holds

The surfaces below track how the app itself names things in its listing and screens. Granularity is what a consented pull can return for a single account.

Routes to the data

Three paths apply to Upstox, and they differ in what they reach and how long they last.

1 · Account Aggregator consent (depository as FIP)

India's NBFC-AA framework moves financial data from a provider to a user with the account holder's explicit, revocable consent. Since SEBI's August 2022 circular, depositories participate as Financial Information Providers, and CDSL was the first to go live; an FIU request can return personal details, ISIN-wise holdings and portfolio value, and transaction history for a chosen window. For settled securities data this is the durable channel — it is a regulated contract, not a screen that shifts. We arrange the FIU-side onboarding and consent wiring with you as part of the build.

2 · Authorized interface analysis of the broker session

Order state, GTT and basket entries, IPO bid status and the funds ledger live in Upstox's own authenticated session rather than in the depository. For these we run documented interface analysis under the account holder's authorization — mapping the token and request chain that the app uses, then re-implementing the calls server-side. Effort is moderate; durability depends on the front end, so we add a re-validation step (see the engineering notes).

3 · User-consented native export

Where a one-off backfill is enough — a consolidated account statement or a contract-note archive — we parse the account holder's own exported files into the same schema. Lowest effort, no live link, useful as a seed or a reconciliation check against the consent feed.

For Upstox the practical recommendation is to take settled holdings and transaction history through the Account Aggregator channel, since it is regulated and stable, then cover the live order, IPO-bid and ledger surfaces with authorized interface work. A consented export earns its place only when a one-time snapshot is all a use case needs. We would build the consent path first and layer the interface work onto it.

A consented holdings call, sketched

Illustrative flow, confirmed and tightened during the build — a consent handle is exchanged for a session, then ISIN-wise holdings are requested for the consented account. Field names are normalized in our output, not copied verbatim.

POST /aa/session            # exchange a granted consent artefact
  { "consent_id": "c-7f3a...", "fi_data_range": "2025-04-01..2026-03-31" }
  -> 200 { "session_token": "st_...", "expires_in": 600 }

GET /portfolio/holdings      # depository-backed, consent-scoped
  Authorization: Bearer st_...
  -> 200 {
       "account": "demat:****1294",
       "as_of": "2026-06-28T09:15:00+05:30",
       "holdings": [
         { "isin": "INE002A01018", "symbol": "RELIANCE",
           "qty": 40, "avg_cost": 2410.50, "ltp": 2978.10, "pnl": 22704.0 }
       ],
       "mf_units": [ { "folio": "91xxxx", "scheme": "Direct-Growth", "units": 512.34 } ]
     }

# error path we handle explicitly
  -> 403 { "error": "consent_revoked" }   # re-trigger consent, never retry blind
  -> 409 { "error": "fi_fetch_pending" }  # poll with backoff, surface partial state

Broker-session surfaces (order book, IPO bids) follow a separate token chain mapped during interface analysis; we keep their fields in the same normalized schema so a consumer reads one shape.

What lands in your repository

Each item is tied to the surfaces above, not a generic checklist:

• An OpenAPI specification covering the holdings, orders, mutual-fund, IPO and ledger endpoints, with the normalized field set.
• A protocol and auth-flow report: the consent-artefact exchange for the depository path, and the token/session chain for the broker-session surfaces, including error and revocation handling.
• Runnable source for the key endpoints in Python or Node.js — the consented holdings pull, order-history fetch, MF and IPO readers.
• Automated tests against recorded fixtures, including the 403 consent-revoked and 409 fetch-pending paths.
• Interface documentation a developer can act on, plus data-retention and consent-record guidance for the AA path.

How consent and the rulebook work here

The dependable basis for the securities data is the account holder's own consent, captured and enforced by an NBFC-AA. The AA is data-blind: it shows the user each request, records consent, moves encrypted data from the provider to the user, and keeps an audit log without decrypting anything. Consent is scoped — to specific data types, a date range, a purpose, and an expiry — and can be revoked, at which point the feed stops. Both ends of the channel must be entities regulated by RBI, SEBI, IRDAI or PFRDA; depositories enter as FIPs under the SEBI circular, and broking houses can act as FIUs. We operate the engagement to match: access is authorized and logged, the pull is data-minimized to the fields a use case needs, consent records are retained, and an NDA covers the work where you want one. Where data is read from the broker session, it stays inside the account holder's authorization.

Engineering notes specific to Upstox

Two things shape the build and we handle both:

• Two sources of truth for one portfolio. Depository data via the Account Aggregator is settled and ISIN-keyed; the broker session carries intraday order state, GTT, basket orders and IPO bids that never reach the depository. We reconcile the two into a single schema and tag every field with its origin, so a holdings figure and an open-order figure are never silently mixed.
• Consent windows and front-end drift. We design the sync around the consent expiry so a feed does not quietly lapse mid-period, and we schedule a re-validation pass that diffs broker-session responses against a known-good shape, alerting and pinning to that shape when a field moves rather than shipping a broken pull.
• Plan and product breadth. Upstox spans equities, F&O, mutual funds, IPOs, fixed income, SGBs and gold; we scope which domains a given integration reads so margin and derivatives surfaces are mapped only when the use case needs them.

Access, sandbox, and any FIU onboarding are arranged with you during onboarding; the build runs against a consenting account or a test fixture.

Pricing and how it runs

Source for the consented holdings pull, the order-history reader and the MF/IPO endpoints is delivered against the surfaces mapped above. Source-code delivery starts at $300: you get the runnable source plus documentation, and you pay after delivery, once the integration runs and you are satisfied with it. If you would rather not host it, call our endpoints instead and pay per call, with no upfront fee. Either way the cycle is one to two weeks. Tell us the data you need from Upstox and which model suits you on the contact page, and we take it from there.

App screens referenced

Store screenshots used while mapping the surfaces above.

Similar apps in the same data space

Indian broking and investing apps hold comparable demat-backed records, which is why a single normalized schema travels across them. Named here for ecosystem context, not ranking.

• Zerodha (Kite) — large discount broker; holdings, orders and the Console statement archive.
• Groww — stocks plus mutual funds in one account; folio and order data.
• Angel One — full-feature broking with research; orders, holdings and SIPs.
• Dhan — trader-focused; options, positions and order book.
• Paytm Money — beginner-friendly stocks and direct mutual funds.
• ICICI Direct — bank-linked full-service broker; holdings and contract notes.
• HDFC Sky — bank-backed broking app; demat holdings and orders.
• Motilal Oswal — full-service broker with advisory; portfolio and trade history.
• mStock — low-brokerage broking; holdings and order records.
• Kotak Securities — bank-linked broking; demat holdings, orders and funds.

Sources and who checked this

Checked on 28 June 2026 against the app's Play Store description and the primary regulatory pages for India's consent framework: the SEBI circular admitting depositories as FIPs, CDSL's investor FIP page on what securities data the channel shares, and the Government of India explainer on the Account Aggregator framework. Holdings, order, MF and IPO surfaces are drawn from the app's own listing.

• SEBI circular — depositories as FIPs in the AA framework (Aug 2022)
• CDSL — Financial Information Provider for demat securities data
• Government of India — Account Aggregator framework overview

Mapped by the OpenBanking Studio integration desk — June 2026.

FAQ

Which Upstox records can a consented integration actually reach?

ISIN-wise equity and ETF holdings, the funds ledger, order and trade history, mutual-fund units with SIP state, IPO applications and allotment outcomes, and profile fields like PAN and demat account number. Each surface maps to a demat record or an in-app statement, so the normalized output mirrors what the account holder sees.

Does securities data go through the same RBI Account Aggregator flow as bank data?

Yes. After SEBI's August 2022 circular, depositories joined the Account Aggregator ecosystem as Financial Information Providers, so ISIN-wise holdings and transaction history for a consenting account flow through an NBFC-AA the same way bank statements do, scoped and time-bound by the consent artefact.

How do you handle the difference between depository holdings and Upstox's in-app order book?

We treat them as two sources. Depository data via the Account Aggregator covers settled ISIN-wise holdings and transactions; intraday order state, GTT entries, basket orders and IPO bid status live in the broker's own session. We reconcile both into one schema and flag which field came from which source.

What keeps a holdings sync from breaking when the app changes?

The consent-based depository path is stable because it is a regulated contract. For surfaces read through the broker session we wire a schema-diff check that runs on a schedule, alerts when a response field shifts, and pins the build to a known-good shape until we re-map it.