i2i APIs
A controlled API gateway for partners, payment providers and device apps
At a glance
- Partner systems create and recharge subscribers by API
- Each client limited by source IP and endpoint
- Every gateway call audited, including rejected ones
- Payment callbacks credited to the customer account
Overview
i2i APIs is the set of interfaces through which outside systems work with i2iCore. Its current core is a curated external gateway. Staff register each client, restrict it to approved source addresses, and choose which endpoints it may call. Every call through the gateway is checked, throttled and written to an audit log.
The gateway exposes subscriber and package operations for partner systems, and device operations for the ACS: reading and changing Wi-Fi settings on a subscriber's equipment. Separate adapters handle payment provider callbacks and bill-payment partners, so payments reach the customer's account without manual entry.
What is an API gateway for an ISP?
An API is the way one piece of software asks another to do something, such as creating a subscriber or checking a bill. An API gateway is the controlled front door for those requests. It decides who may call, which operations they may use and how often, and it keeps a record of what happened.
For a telecom operator this matters because the systems that call in are not all your own. Resellers run their own CRMs, bill-payment aggregators post payments, and partner apps read subscriber data. Without a gateway, each of them needs direct access to internal services, and no one can say afterwards who did what.
In i2iCore the external gateway is deliberately curated. It does not expose the internal portal endpoints. It publishes a chosen set of operations, each of which can be enabled or disabled, and it accepts only registered clients calling from approved addresses. Operators manage clients, endpoints and the call log in the identity console under External API.
Capabilities
What i2i APIs does
Subscriber and package API
- Create, edit, recharge and deactivate subscribers
- Cancel a recharge and set or read grace periods
- Online status for one or many subscribers
- MAC reset, daily usage and package list
Device API
- Device information by service account
- Read and change Wi-Fi settings and password
- Operation status for a requested change
Client control
- Clients registered by staff, not self-registered
- Sign in by client secret or as an identity-service user
- Source IP and address-range allow-list
- Enable or disable each endpoint
- Throttling with a retry-after response
Audit and operations
- Every gateway call logged with outcome, including rejected calls
- Search the call log and download it as CSV
- Rotate a client secret and revoke its sessions
- Interactive Swagger documentation
Payments and partners
- Razorpay and AblePay callbacks for payments
- Bill fetch and payment posting for NPay, DemandPay and BharatPay
- ERP partner API for customers, invoices, plans and renewals
Use cases
Where i2i APIs is used
A reseller's CRM creates and recharges subscribers
A franchise runs its own CRM. Staff register it as a client with its office IP range and enable the subscriber endpoints. The CRM signs in, creates a subscriber, recharges a package and deactivates an account, and every call appears in the audit log with its outcome.
A payment provider confirms a payment
A customer pays online through a supported provider. The provider calls the callback endpoint and i2iCore records the payment against the customer's account, so support does not need to key it in by hand.
A bill-payment aggregator fetches and posts bills
An aggregator that collects payments at retail points calls the partner bill-pay endpoints to fetch a subscriber's bill and later posts the payment. The operator sees the calls and their outcomes in the same call log.
A partner app changes a subscriber's Wi-Fi password
A partner's app lets its customer choose a new Wi-Fi password. The app calls the device endpoints as a service account, reads the operation status and confirms the change, while the operator keeps control of which devices and endpoints it may use.
FAQ
i2i APIs: frequently asked questions
Can any developer sign up and start calling the APIs?
No. Clients are registered by operator staff in the identity console, and each is tied to an address allow-list and a set of enabled endpoints. This is deliberate: an operator should know who is calling. Unknown paths are rejected.
How do callers authenticate?
A registered client can sign in with a client code and secret, or as an identity-service user whose password is verified there. Either way it receives a token, and the source address must match the allow-list on every call.
Is there rate limiting?
Yes. The external gateway throttles calls per client and endpoint and returns a retry-after response when the limit is reached, so a client that sends too many calls is told to wait. Ask us about limits for your expected volumes.
Does i2iCore push events to our systems?
No. Outbound event delivery is not part of this offering. The gateway responds to calls from your systems, and payment providers call in to i2iCore. If you need to be told of changes, your systems would poll the relevant endpoints. Tell us about the requirement.
What does the API cover?
Subscriber and package operations, device operations for the ACS, payment provider callbacks and partner bill-pay interfaces. It does not cover every part of the platform: for example, there is no external interface here for AAA policy, network monitoring or inventory.
How are the APIs documented?
Services expose Swagger documentation generated from the code, and the subscriber and package interface has a written specification. Endpoints carry a version in the path where one applies. A published, versioned reference and a deprecation policy are not yet available.