I Reverse Mapped the GST Portal's Hidden Notice APIs
Notes from actually mapping how the GST portal serves notice and case data internally, and why building on top of it is harder than it looks from the outside.
The GST portal has no public API for notices. If you want to build anything on top of it, you are working from the same session-authenticated calls the browser makes, which means you first have to find them.
That took longer than the actual integration.
Case data is not exposed as one clean resource. A single logical case (a show cause notice, its replies, its hearing, its order) is scattered across separate calls keyed by different identifiers depending on which module issued it. Litigation cases use one reference format. Recovery proceedings use another. Refund-linked notices reuse the ARN from an entirely different workflow. None of these identifiers are consistently cross-referenced in the responses.
The CAPTCHA and OTP flow is the easy part, everyone assumes that is the hard part and it is not. The hard part is that the portal's own internal structure was clearly built module by module over years, by different teams, with no shared notice schema. Reconstructing "here is everything open for this GSTIN, ranked by deadline" means stitching together five or six separate data shapes into one, and keeping that mapping correct every time the portal ships a change nobody announced.
We did it because the alternative was accepting that practitioners check five different screens per client, every day, forever, and call that a solved problem.
If your compliance software just says "we pull from the GST portal," ask what that actually means. It is doing a lot of quiet work, or it is doing very little.