Skip to main content
Holdings are the folios and units a customer currently owns, as reported by the registrars — CAMS and KFintech. They are refreshed once a day from the registrars’ own reports, so they are a daily snapshot, not a live portfolio. They are not derived from the orders you placed through this API: they cover every folio under your distributor code, including customers you have not onboarded here yet. There are two ways to read them:
  • By investor — GET /api/investors/v1/{investor_id}/holdings, for a customer you have registered.
  • By PAN — POST /api/holdings/v1/lookup, for any customer, onboarded or not.

By investor

Response 200:

By PAN

Use this for an existing customer who isn’t an investor on the platform yet. The PAN goes in the request body (never the URL, so it stays out of logs and proxies) and comes back masked.
Response 200 — the same positions and summary as above, with pan in place of investor_id:
Nothing reported for the PAN returns 200 with "holdings": [].

Fields

How positions are matched to the scheme and AMC masters

The registrars identify a position by their own codes, so each position is matched to our masters when the data is loaded, letting you process holdings by whichever identifier your system uses.
  • A position is matched only to schemes of your account’s plan — regular by default, or direct if your account is set up for direct plans (a scheme of the other plan never matches) — by ISIN first (KFintech reports carry one), then by the registrar’s product code.
  • A registrar product code usually corresponds to several scheme listings, for two different reasons:
    • Order-tier duplicates — the same scheme listed with and without an -L0 / -L1 order-tier suffix. The base scheme (no tier suffix) is used and, if several remain, the one with the lowest minimum purchase. Its NSE code is returned as scheme_code.
    • Different variants of the fund — growth, IDCW payout and IDCW reinvest options, and each IDCW frequency, each with its own ISIN. The registrar’s product code does not say which one the investor holds, so scheme_code is left empty rather than guessing an option that could place an order on the wrong plan. Resolving the exact variant and ISIN is planned once transaction data is available.
  • fund_name identifies the fund but not necessarily the exact plan/option, and in rare cases it can be a sibling fund of the same AMC that shares the code. isin / rta_code are filled only when all matching listings agree on them (tier duplicates do). An empty scheme_code is normal, not an error.
  • amc_name is mapped from the registrar’s amc_code via our AMC master. When nothing matches it is empty and amc_code is still returned.
  • Matching is redone on every daily load, so positions improve as the masters do.

Things to know

  • Daily refresh. A new day’s report replaces the previous one; a folio that disappears from the report (fully redeemed or transferred) disappears from the list.
  • Empty is normal. holdings is [] until a registrar report covering the PAN has been processed — for a newly registered investor this can take a day or more. It is not an error.
  • Primary-holder folios only. The registrar reports identify a folio by its primary holder’s PAN. A joint folio therefore appears under the primary holder’s PAN, never a secondary holder’s, and investors registered with a joint holding type always return an empty list on the by-investor endpoint.
  • No cost or invested amount — the registrar reports don’t include it.
  • Not live. Orders placed today won’t show until the registrars report them.

Errors