CDSL now exposes twenty-one API products to Depository Participants — enough to run account maintenance, pledges, eDIS, early payin, dematerialisation tracking and reporting without a single manual file drop. Here is the full map, and an honest look at what it takes to stand behind all of it.
Twenty-one products, one habit to break
For most DPs, “talking to the depository” still means a folder: a signed batch dropped into an upload window at a fixed hour, a status checked by hand the next morning.
CDSL’s API handbook shows us the alternative. Account opening and modification, transaction upload, margin pledge and repledge, unpledge and confiscation, the full electronic delivery instruction slip (eDIS) family, early payin, dematerialisation status tracking, off-market beneficiary addition, account transfer-cum-closure, and periodic report delivery — all of it is reachable as an API today, not just the two or three flows most back offices have gotten around to automating.
Three ways a request actually travels
What is harder to see from the handbook alone is that these twenty-one products don’t share one shape. They share a vendor. What actually determines the engineering work isn’t what an API does, but how its request travels — and there are three distinct patterns.
| Lifecycle | How it works | Carries |
|---|---|---|
| Batch + poll | The DP signs and uploads a batch (CSV wrapped in a password-protected ZIP), then polls a status-inquiry endpoint on a timer until CDSL has finished processing, then pulls the response file down. | BO Setup Upload, BO Modify Upload, Common Upload API (auth, transaction upload, status inquiry, download). |
| Direct request–response | A single signed JSON call, answered synchronously in the same round trip. No polling, no investor involved — the closest thing here to a conventional REST integration. | BO Active Demat Account, Early Payin (Setup & Inquiry), EDIS Inquiry, BO EDIS TPIN Generation, SFTP Report Setup. |
| Investor OTP redirect | The DP posts a redirect form; the investor’s own browser lands on a CDSL-hosted page, enters an OTP, and CDSL redirects back to a DP-hosted callback URL with the result. The DP is a bystander for the middle of its own transaction. | Add Beneficiary (Off-Market), DESTAT, EDIS Request, and the entire pledge family — Margin Pledge Setup/Inquiry, Margin Repledge, Normal Pledge, Unpledge/Confiscate. |
The first lane is the one automation already replaces in production: myDP already gives investors a screen, but underneath it, that instruction still lands in our own file-based systems before reaching CDSL — two hops, not a person typing anything by hand, but not a direct call either. The other two lanes are what let that second hop disappear: a direct system-to-system call, or an investor-authorised OTP redirect, both landing straight at CDSL without stopping at a file in between. Together, the three lanes are the automation pathway for a DP — not manual versus automated, but how many hops sit between an investor’s instruction and CDSL actually receiving it.
What automating the rest actually buys a DP
Each family replaces a specific manual workflow, not just “a form on a portal.”
| Area | What changes |
|---|---|
| Margin pledge | Pledge, repledge and unpledge move from portal data-entry to a signed API call authorised by the investor directly — faster margin availability for trading clients, and native support for SEBI’s margin pledge system instead of a manual workaround. |
| eDIS | Investors authorise stock delivery with an OTP instead of a paper Delivery Instruction Slip — removing the single biggest forgery vector in the settlement chain, and shrinking same-day turnaround. |
| Early payin | Setup and inquiry in one request-response pair means fewer securities missing the clearing corporation’s payin deadline, and the exchange penalties that follow. |
| DESTAT | Dematerialisation status becomes a query instead of a phone call — “where is my demat request” stops being a support ticket. |
| Report setup | Periodic reports arrive pushed to a DP-hosted endpoint instead of being pulled by hand from a portal — one fewer recurring task standing between CDSL and the DP’s own reconciliation. |
| Account transfer | Transfer-cum-closure and off-market beneficiary addition move at API speed instead of portal-form speed — the difference shows up most at account exit, when clients are least patient. |
The instruction doesn’t stop at CDSL
Wiring twenty-one endpoints is not the same as running a back office on top of them.
Every instruction a DP sends is part of a larger business event. A margin pledge must be recorded at CDSL, reflected correctly in the client’s account, recognised in the broker or clearing member’s collateral records and, where applicable, repledged to the clearing corporation. An early-payin instruction is useful only if the securities are identified against the correct settlement and made available to the clearing corporation within the settlement timetable. A dematerialisation request must progress consistently through the DP, the depository and the issuer or its RTA. An inter-depository transfer must leave the source account and reach the correct account at the other depository without quantity, ISIN or beneficiary mismatches.
The API response covers only CDSL’s part of that journey. It does not tell the DP whether the broker has recognised the collateral, whether the clearing obligation has been satisfied, whether an RTA-side dematerialisation exception remains unresolved, or whether a downstream internal ledger failed to post an otherwise successful instruction. Those are not necessarily failures of the CDSL API. They are gaps the DP’s back office must detect and close.
That is what makes a DP back office unusually demanding. It does not reconcile against one self-contained source of truth. Depending on the workflow, it may have to keep the DP’s own books aligned with CDSL or NSDL, the broker or clearing member, the clearing corporation, the issuer or RTA, and sometimes the banking system. Each participant operates on its own clock, exposes different statuses, and defines “complete” at a different point in the journey.
Getting twenty-one API calls to return success is therefore table stakes. The real job is knowing whether each business instruction has reached its final outcome across every relevant party — and finding the break when it has not.
That capability does not arrive as another endpoint in the API handbook. It is the layer above the wire protocol: a control ledger that follows each instruction through the systems relevant to its lifecycle; reconciliation that distinguishes “accepted by CDSL” from “completed end to end”; exception queues that tell operations what is stuck, where, and for how long; and a dashboard that turns several independently run systems into one coherent answer to a simple question:
Where does this account — or this instruction — actually stand right now?
That is the layer KCS has spent more than two decades building, one workflow and one exception path at a time. It is also where most of the real back-office work lives.
CDSL exposes twenty-one API products. A back office makes sure the business instruction behind each call reaches its final, reconciled outcome.
Grounded in CDSL’s 2026 API Handbook for Backoffice Vendors of DPs.
