Understanding KwikAPI API Rate Limits
Important: API Rate Limits Do Not Mean Your Transactions Are Limited
Some users see limits such as 10/day, 20/day, or 100/day in the API documentation and assume that KwikAPI allows only a limited number of transactions per day.
This is not correct.
The limits shown for specific APIs mainly apply to system information, synchronisation, monitoring, and status APIs. These APIs return data that generally does not need to be requested repeatedly because it can be stored or cached in your own application.
Your transactional APIs, such as Recharge, Bill Payment, Payout, and other services, have limits configured separately based on your account and approved use case.
Why Are Some APIs Rate Limited?
Different APIs serve different purposes.
For example, an API that provides the complete list of operators does not need to be called every time a customer opens your recharge page.
Instead, your application should:
- Call the API when required.
- Store the response in your own database or cache.
- Use the locally stored data for your customers.
- Refresh the data periodically.
This approach provides:
- Faster response times for your customers.
- Reduced unnecessary API requests.
- Better system performance.
- More reliable application architecture.
- Protection against accidental or excessive repeated requests.
Simple Example: Biller List API
Incorrect Understanding
“My Biller List API limit is 20/day. Does that mean I can process only 20 bill payments per day?”
No.
The 20/day limit applies only to requests made to the Biller List API itself.
It does not mean you can process only 20 transactions.
Correct Implementation
Suppose you operate a website or application with 10,000 customers.
You can call the Biller List API to download the available billers and operator information, store that data in your own database, and use it for your customers.
For example:
KwikAPI → Your Database → Your Customers
You do not need to call KwikAPI’s Biller List API every time a customer opens the bill payment page.
You should use your locally stored data and refresh it periodically.
Therefore, a limit of 20 requests per day is normally sufficient for synchronisation purposes.
API Limits Explained
1. Service Category List — 10 Requests per Day
This API provides the available service categories.
Examples:
- Prepaid
- DTH
- Electricity
- Gas
- Water
- Broadband
Recommended Usage
Fetch the categories and store them locally.
You generally do not need to call this API every time a user visits your application.
Example
If your application has 100,000 users, you can still use the same locally stored category list for all 100,000 users.
The 10/day limit applies to API requests, not to the number of customers using your application.
2. Biller List — 20 Requests per Day
This API provides the list of available operators and billers.
Recommended Usage
Synchronise the data with your database and refresh it periodically.
For example:
Your server calls the Biller List API → stores the operator list locally → your application reads the data from your database.
Important
20 API requests per day does not mean 20 customer transactions per day.
You can process transactions separately according to your account configuration.
3. Biller Details — 20 Requests per Day
This API provides detailed information about operators and billers, including supported parameters.
It also supports batch lookup, allowing multiple operator IDs to be requested together where applicable.
Recommended Usage
Fetch and store biller configuration locally.
For example, if you need information for multiple billers, do not repeatedly request the same details every time a customer starts a transaction.
Store the information and refresh it when required.
4. Circle Codes — 2 Requests per Day
Circle codes change very rarely.
For this reason, your application should fetch the circle list and store it locally.
Example
You may download the circle list during application setup and continue using the same stored data.
There is normally no need to call this API repeatedly throughout the day.
2 requests per day is intended for data synchronisation, not customer usage limits.
5. Wallet Balance — 48 Requests per Day
This API allows you to check your KwikAPI wallet balance.
The default limit is approximately suitable for checking the balance periodically rather than requesting it after every action.
Example
A system can check the wallet balance at scheduled intervals, such as every 30 minutes.
48 requests per day provides an average of one request every 30 minutes.
For accounts with a valid higher-frequency use case, the limit may be increased based on account performance and approval.
6. Transaction Status — 100 Requests per Day
This API is primarily used to check the status of transactions when the original transaction response is PENDING or unclear.
Example
Suppose a recharge request returns:
SUCCESS
No additional status request is normally required.
If it returns:
PENDING
Your system can check the Transaction Status API after 30–60 seconds and retry status checking only when required.
Recommended Practice
Do not continuously poll the same transaction.
For example:
❌ Incorrect:
Check the same transaction every second.
That could generate:
60 requests per minute for one transaction.
Instead:
✅ Recommended:
- Transaction returns
PENDING. - Wait 30–60 seconds.
- Check the transaction status.
- If still pending, check again after an appropriate interval.
- Use a controlled maximum number of retries.
The default limit is 100 requests per day, and higher limits may be approved based on account performance and your genuine business use case.
7. Last 100 Transactions — 48 Requests per Day
This API returns your latest 100 transactions and is primarily intended for:
- Dashboards
- Reconciliation
- Transaction monitoring
- Internal reporting
Example
Instead of requesting this API every time a dashboard page is opened, your system can synchronise transaction data periodically and store it in your own database.
For example:
KwikAPI → Your Database → Your Dashboard
This prevents every dashboard visitor from generating a separate API request.
What About Transactional APIs?
This is the most important point.
Transaction APIs Are Not Automatically Restricted to 10, 20, 48, or 100 Transactions Per Day
The limits listed above apply specifically to the APIs shown in the rate limit table.
Other APIs are configured per account.
Depending on your approved services and account configuration, this includes APIs such as:
- Prepaid Recharge
- DTH Recharge
- Utility Bill Payments
- Bill Fetch
- Payout / Money Transfer
- Account Verification
- Operator & Circle Detection
- Recharge Plans
- DTH Plans
- R-Offer Check
Your permitted usage for these APIs depends on your account configuration and approved use case.
If you expect high traffic or require a specific API capacity, please contact support before implementation so that the appropriate configuration can be reviewed.
Example: A Recharge Business Processing 5,000 Transactions Per Day
Suppose your application processes 5,000 recharge transactions per day.
This does not mean you need to call every system API 5,000 times.
A typical implementation could look like this:
Once or periodically:
- Download operator/biller information.
- Store it in your database.
- Refresh it according to your application requirements.
For every customer transaction:
- Process the actual recharge through the relevant transaction API.
- Check transaction status only when the original response is
PENDINGor requires confirmation.
Therefore:
5,000 customer transactions do not automatically result in 5,000 calls to Service Category List, Biller List, Circle Codes, or other synchronisation APIs.
The API architecture should separate reference data from real-time transactional requests.
Example: Correct Application Architecture
A recommended architecture is:
Step 1: Synchronise Reference Data
Your backend periodically fetches information such as:
- Service categories
- Biller lists
- Biller details
- Circle codes
Step 2: Store Data Locally
Save this information in:
- MySQL
- PostgreSQL
- Redis
- Another suitable database or caching system
Step 3: Serve Your Customers from Your Own System
When a customer opens your application, your application reads the required operator and service information from your local database.
Step 4: Call KwikAPI When a Real-Time API Request Is Actually Required
Examples include:
- Processing a recharge
- Paying a bill
- Fetching a bill
- Checking a pending transaction
- Processing a payout
- Verifying an account
This approach is faster, more scalable, and avoids unnecessary API calls.
Frequently Asked Questions
Q1. Does a limit of 20/day mean I can process only 20 transactions per day?
No.
A 20/day limit applies only to the specific API on which that limit is mentioned.
For example, Biller List — 20/day means your account can call the Biller List endpoint up to 20 times in the applicable daily limit period.
It does not mean your overall transaction volume is limited to 20 transactions.
Q2. Why should I store API data locally?
Some information does not change frequently.
Examples include:
- Service categories
- Circle codes
- Operator lists
- Biller configuration
Calling an external API every time a customer requests this information is unnecessary.
Local storage improves:
- Application speed
- Scalability
- Reliability
- User experience
Q3. Can all my customers use the same synchronised data?
Yes.
For example, your application can fetch and store the Biller List once and use that locally stored information to serve all customers.
You do not need one Biller List API request per customer.
Q4. Does the Transaction Status limit mean I can have only 100 transactions per day?
No.
The Transaction Status API is used to check transaction results, particularly when a transaction remains pending or its status needs confirmation.
A successful transaction does not normally require repeated status polling.
The 100/day limit applies specifically to status-check requests, not directly to your total transaction volume.
Q5. What should I do if my transaction returns PENDING?
Do not immediately create a new transaction with the same order.
Instead:
- Keep the original
order_id. - Wait for the recommended interval.
- Check the Transaction Status API.
- Retry status polling only in a controlled manner.
- Do not continuously poll the same transaction.
This helps prevent duplicate transactions and unnecessary API usage.
Q6. Can Wallet Balance or Transaction Status limits be increased?
Yes, subject to approval.
Wallet Balance and Transaction Status limits may be increased based on factors such as:
- Account performance
- Business volume
- Actual use case
- Technical implementation
- Request pattern
Please contact support with your requirement.
Q7. What does “Per Account” mean?
“Per Account” means the applicable usage configuration depends on your specific KwikAPI account and approved service requirements.
If you require higher capacity or expect significant traffic, please contact support to discuss your expected usage.
Q8. Should I call every API whenever a customer visits my website?
No.
This is not recommended.
Your application should cache or store synchronisation data locally and call real-time APIs only when the data genuinely needs to be requested or a transaction needs to be processed.
Quick Summary
|
API Type |
How It Should Be Used |
|---|---|
|
Service Categories |
Fetch and store locally |
|
Biller List |
Synchronise and cache locally |
|
Biller Details |
Store configuration locally |
|
Circle Codes |
Fetch and cache locally |
|
Wallet Balance |
Check periodically |
|
Transaction Status |
Use mainly for pending/unclear transactions |
|
Last 100 Transactions |
Use for reconciliation/dashboard synchronisation |
|
Transactional APIs |
Usage configured according to your account and approved use case |
Final Clarification
The rate limits displayed in the KwikAPI documentation are API-specific limits. They are not a blanket limit on your total number of customers or transactions.
For example:
Biller List: 20/day does not mean 20 bill payments/day.
Circle Codes: 2/day does not mean 2 transactions/day.
Transaction Status: 100/day does not mean 100 transactions/day.
The listed limits apply to requests made to those specific endpoints.
For high-volume implementations, the recommended approach is to synchronise reference data with your local database or cache, while using KwikAPI’s real-time and transactional APIs according to your account configuration.
For account-specific capacity requirements, please contact KwikAPI Support.
Related Documentation
Please refer to the complete KwikAPI API Reference for endpoint details, parameters, response formats, and implementation guidance: