GST e-invoice API access: why integrators need a fixed IP

You've passed the sandbox tests and you're applying for production access to NIC's e-invoice system. The form asks for your static IP addresses. Here's why, how many to give, and how to avoid getting stuck later.

Last updated 29 October 2026 · 4 min read

For direct API access to the GST e-invoice system, NIC only accepts calls from Indian public static IPs that it has whitelisted for you. You can register up to four. Whitelisting takes a few days, and changing the addresses later takes longer. So the IP you give NIC needs to be one you'll still have next year. If your servers don't have a fixed Indian address, a static IP for the GST e-invoice API gives your integration one. First, check that direct access is the right route for you at all.

Do you actually need direct access?

Most businesses don't connect to NIC themselves. They generate e-invoices through their accounting software or a GSP (GST Suvidha Provider), and the GSP connects to NIC on their behalf. If that's you, the GSP handles the whitelisting on its side, and you probably don't need a static IP for e-invoicing at all. Ask your GSP before buying anything.

Direct access is for two groups:

• Large taxpayers above NIC's turnover threshold who want to integrate their own ERP straight with NIC. The current figure is on NIC's onboarding page.
• GSPs, ASPs and software companies that build e-invoicing for many clients and connect to NIC themselves.

If you're in either group, read on.

What NIC asks for

NIC's onboarding page lays out the process. In short:

1. You test your integration in the sandbox.
2. You submit a summary test report.
3. NIC evaluates it and grants production access.
4. As part of that, NIC whitelists a maximum of four Indian public static IP addresses for you.

Two lines on that page are worth reading twice. Verification and whitelisting may take four to five days. And once IPs are whitelisted, changing them takes more time.

NIC's e-way bill API works on the same idea. Its API manual says the calling system should have a static IP address, which you enter when registering for API access. That manual dates from 2018, so check the current rules on the e-way bill portal, but the principle hasn't changed.

Why "Indian" and "static" both matter

Static, because NIC only accepts calls from the addresses on your list. If your production server's outbound address changes, IRN generation stops. Then you're waiting days for a new whitelisting while invoices pile up.

Indian, because NIC asks for Indian addresses specifically. This catches teams whose servers run in a cloud region outside India. IRIS IRP's developer docs even note that providers without an Indian IP can connect through its GSP gateway instead. If your stack lives in Singapore or Frankfurt, you need an Indian address for these calls.

Where the outbound IP usually goes wrong

• Cloud servers without a fixed outbound address. A rebuilt instance, a new node, or autoscaling can bring a new IP.
• Containers and Kubernetes. Pods leave through whichever node they're on, so the NIC client's address depends on scheduling.
• Office lines. Unless the ISP gave you a static IP on a business plan, the address can change after a restart or a line change.
• Disaster recovery. Teams whitelist the primary data centre and forget the standby. The day they fail over, e-invoicing stops.

Before you fill in the form, run this on every machine that will call NIC:

curl -4 https://ifconfig.co

If the answers differ between machines, or could change, fix that first.

Ways to give NIC an address that won't move

Fixed IPs from your data centre or cloud

If your servers are in an Indian region, most cloud providers let you attach a fixed public IP, or send traffic out through a NAT gateway with a fixed address. Make sure every component that calls NIC goes through it, standby included.

A dedicated static IP for the NIC calls

This is what we offer at TrueIP. You get a dedicated IPv4 in Mumbai, from our own routed address range, with its own proxy login. Set it on the HTTP client that calls the IRP. Those calls leave from that Indian address, whichever server or region they run from. The rest of your traffic is untouched.

import requests

irp = requests.Session()
irp.proxies = {"https": "http://USER:PASS@HOST:PORT"}
# IRP_HOST and paths come from NIC's docs for your environment
r = irp.post(f"https://{IRP_HOST}/...", json=auth_payload)

The API is HTTPS, so it stays TLS encrypted end to end. We see the destination host, not invoice data or credentials. A sensible setup is two IPs, one for production and one for the standby, both registered with NIC.

Test from the setup you'll run in production

NIC's page doesn't spell out whether the sandbox itself needs a whitelisted IP. Either way, it pays to run your sandbox tests from the same route you'll use in production: the same proxy or gateway, the same outbound address. Then nothing changes between the test report and go-live except the endpoint and credentials.

Keep a simple record of your four slots too: which address, which machine or environment uses it, and who to call if it changes. It sounds like admin work. It's what saves you days when a server gets replaced in a hurry.

IPv4 or IPv6?

NIC's page asks for Indian static IP addresses and doesn't say IPv6 is accepted. Use IPv4.

Quick checklist

• Confirm you need direct access. If you file through a GSP, ask them first.
• Run curl -4 https://ifconfig.co on every machine that will call NIC, standby included.
• Make sure each address is Indian, public and won't change.
• Register up to four, with a plan for primary and standby.
• Expect four to five days for whitelisting, and longer for any change, so get it right the first time. A static IP for the GST e-invoice API is one way to do that.

Keep reading