Skip to main content
Every API has limits. Limits protect every partner on the platform (including you) from one application monopolising shared infrastructure. Understanding how our limits work prevents surprises in production.

Two Types of Limits

Rate Limits

The maximum number of requests allowed within a short time window (seconds or minutes). Rate limits prevent burst abuse: for example, a loop in your code that fires 500 requests in one second.

Quotas

The maximum number of requests allowed within your billing period (typically one month). Quotas are determined by your partner plan. Hitting a quota means you have used your allocation for the period, not just a short burst.
A rate limit violation returns HTTP 429 Too Many Requests. A quota exhaustion returns HTTP 402 Payment Required. Both include headers that tell you exactly what happened and when you can retry.

Rate Limits by Endpoint

These limits apply per API key unless otherwise noted. “Per IP” limits apply per source IP address regardless of key. Burst is the maximum number of requests per second within the window. Even if you have quota remaining, sending requests faster than the burst rate will trigger a 429.
The /api/Auth/ endpoints use IP-based limits, not key-based limits, because they are called before you have authenticated. If you have multiple services behind a single NAT IP, they share this limit.

Response Headers to Monitor

Every API response includes headers that tell you where you stand. Read these in your application. Do not rely on hitting a 429 to detect a limit.
Log X-Quota-Remaining in your application metrics. Set an alert when it falls below 20% so you have time to contact us before you are completely blocked.

What to Do When Rate Limited (HTTP 429)

A 429 response means you sent requests too fast. The right response is exponential backoff with jitter: wait a little, retry, wait a little longer if it fails again, and so on. Do not retry immediately in a tight loop. That makes the problem worse.
The jitter (random extra delay) is important. Without it, all your retry attempts fire at the same moment, creating a “thundering herd” that immediately triggers another rate limit. Jitter spreads the retries out in time.

What to Do When Quota Is Exhausted (HTTP 402)

A 402 Payment Required response means you have used all the requests in your plan for this billing period. Unlike a rate limit, waiting and retrying will not help. You need to either wait for the reset date (shown in X-Quota-Reset) or upgrade your plan. To discuss your current quota, upgrade your plan, or request a temporary increase for a high-volume event (such as a product launch), email baas-support@unionbank.ng with:
  • Your Partner ID
  • Your current plan
  • The volume you expect and the timeframe
Give us at least 5 business days’ notice for quota increases. Same-day increases are not guaranteed.

Sandbox vs Production Limits

Sandbox has the same rate limits as production. This is intentional. If sandbox had no limits, you would build and test your application without backoff logic, and then hit production limits immediately on launch. The sandbox limits ensure that your retry and backoff logic is tested and working before you go live.
Test your backoff logic explicitly in the sandbox. Write a test that sends requests in a tight loop until it gets a 429, then verify that your application handles it gracefully and recovers.