GST portal API access still says "denied"? Here's what the 3-click guides don't cover

Every guide to enabling GST portal API access ends at the same screen — flip a toggle, pick a duration, click Confirm, done. What they don't cover is what happens next: the same "access denied" message showing up for four different reasons, only one of which is actually about permissions.

One screen, several different callers

Whatever third-party software talks to your GSTIN's data on the GST portal — a filing tool, a lending platform, a reconciliation product — routes through the same authorisation screen. Log in at www.gst.gov.in, click your name (top right) > My Profile, then Manage API Access under Quick Links, select Yes under Enable API Request, pick a duration, and click CONFIRM. That's the whole happy path, and every guide — Zoho's included — stops there.

What none of them cover is that the exact same "access denied" wording shows up for reasons that have nothing to do with whether you completed those five clicks. Below are the four distinct failure modes behind it, in the order worth checking.

1. The grant is time-bound, and it has already lapsed

Enabling API access isn't a permanent switch — the Duration dropdown is the point. Zoho's own setup page doesn't document what the dropdown's options are or how long a selected window actually lasts once confirmed; it only says to pick one and confirm.

Once the window closes, every tool authorised under it — whether that's a filing product, a reconciliation tool, or a lending platform reading your return data — starts getting the same denial, and nothing on their end can renew it. Only re-confirming on the GST portal itself does.

The fix for this one is boring on purpose: re-run the five clicks above, and put a recurring reminder against whatever window you picked, in the same calendar you'd use for a filing deadline — not a memory of "I did this once."

2. "The requested URL was rejected. Please consult with your administrator."

This is a different message from "API access denied," and it's worth not conflating the two. GSTN does not document this message — it is not in GSTN's own Known Issues & Suggested Solutions. The string is the standard block page of an F5 BIG-IP ASM web application firewall, which returns it with a support ID when a request trips a security rule (F5 KB K000156619); the GST portal serves such a page at gst.gov.in/error/system. On that reading it means the request was blocked at the edge before anything checked your permissions — but that inference is ours, not GSTN's, and we cannot confirm which portal screens it fronts. Typically it's something about how the request arrived rather than anything about your account's authorisation state: a stale bookmarked link, a browser extension rewriting the request, or a network path (a corporate proxy, a VPN, certain mobile carrier NAT setups) the portal's edge protection doesn't like.

Because it looks identical in tone to a permissions error, it's easy to spend time re-checking Manage API Access settings that were never the problem. If you see this specific wording, the useful next steps are: clear cookies and site data for gst.gov.in (a stale or corrupted session cookie is the most common trigger of this kind of block elsewhere on the portal), retry from a plain browser session with extensions disabled, retry off any VPN/proxy, and if it persists, raise it with the GST helpdesk quoting the support ID — re-toggling API access won't touch it, because the request never got that far.

3. The OTP never arrives

Confirming a Duration selection, like several other actions on the portal, is often gated behind an OTP sent to the mobile number or email on your GST registration (GSTN does not document this step itself; it's described consistently across ASP/GSP setup guides) — not whatever number or inbox you're actually checking. Before assuming the portal's OTP delivery is broken, the return address you can check for yourself is worth ruling out first: the mobile number and email on file are whatever was entered at registration (or last amended), and a missed OTP is frequently that address being stale rather than a delivery failure. If the number/email is confirmed current and the OTP still isn't landing, wait for the resend window rather than repeatedly requesting, and check the standard blockers on the receiving end (spam folder, DND settings on the mobile number) before treating it as a portal outage.

4. Jan Samarth shows the same message, for the same reason

Jan Samarth — the government's loan-scheme portal — pulls a business's GST return data the same way any other third-party tool does: through the API channel that Manage API Access authorises. There's nothing loan-platform-specific about the "access denied" it shows; it's the identical grant, on the identical screen, that a filing or reconciliation tool needs. If Jan Samarth (or any similar platform) shows the error, the fix is the same five clicks above on your own GST portal login for the GSTIN the application concerns — not a Jan Samarth setting, because there isn't one on that side to change.

One thing worth ruling out if you manage more than one GSTIN: Manage API Access authorises per login session, against whichever GSTIN you're logged in as. Authorising the wrong one, or the wrong login where multiple people have access to the same PAN's registrations, produces the identical denial for the GSTIN that actually needed it.

The second "Manage API Access" — for e-invoicing specifically

Everything above concerns the main GST portal's authorisation for return-side API pulls (GSTR-1, GSTR-2B, and similar). e-Invoicing runs through a separate system entirely — an Invoice Registration Portal (IRP); Notification 69/2019-CT notifies einvoice1–10.gst.gov.in for this purpose — einvoice1.gst.gov.in is NIC's own portal (with einvoice2 as its same-login failover), and the remaining hosts are GSTN-authorised private IRP operators (Cygnet, ClearTax, EY, IRIS among them) a taxpayer can choose to register through instead, not an assignment based on where the GSTIN is registered — with its own "Manage API Access", documented for one such IRP at IRIS IRP's documentation of its own Manage API Access, and confusing the two is a real source of the same error showing up for a different reason. The IRP's version exists so a taxpayer can authorise a specific "API user" — in practice, a GSP (GST Suvidha Provider) that a filing tool like Zoho Books or Tally routes through — to make e-invoice API calls, including generating an Invoice Reference Number (IRN), on the taxpayer's behalf. As covered in our Zoho Books e-invoicing setup guide, this is done by registering "Through GSP" on the IRP side and naming the GSP by name — a step entirely separate from the return-side Manage API Access screen, done once per GSTIN.

Practically: if your GSTR-1/GSTR-2B pulls work fine but e-invoice/IRN pushes specifically show access denied, re-checking the main Manage API Access screen won't fix it — the e-invoicing-side authorisation is what needs re-confirming, separately.

Before you raise a support ticket

How Recoup fits in

Recoup doesn't manage this authorisation for you — it's your GSTIN's own grant to make, on the government's own screens. What Recoup does is notice when the API session behind it has quietly lapsed: a silently-expired grant doesn't just block whichever tool you were watching, it stalls every scheduled GSTR-2B pull into any downstream reconciliation tool that depends on it — including this one — and, per Section 16(2)(aa) read with Rule 36(4), your ITC only stands once the supplier's invoice is actually communicated in your 2B. A pull that silently stopped running is painful to catch manually — by the time someone notices, it's usually a filing cycle behind, not a day.

Related guides