The TabaPay platform is designed for real-time, evenly distributed traffic, not batching or bursts. To help ensure reliable, real-time transaction processing, this guide will define how you should send API traffic and how TabaPay behaves under high load.
Rate Limit Policy
TabaPay does not enforce fixed per-endpoint rate caps under normal operating conditions.
For optimal performance, you should target approximately 1 transaction per second (TPS) and generally remain within 3–5 TPS, unless otherwise coordinated with TabaPay.
Rate limits and a 503 error are triggered when traffic patterns are unusually high or disruptive, such as:
- Sudden API request bursts
- Large batches of queued transactions submitted simultaneously
- Sustained abnormal request velocity
This approach allows us to process and return requests for all clients as soon as they are received. In turn, this keeps the platform stable, scalable, and elastic for everyone.
Network Batching vs API Request Batching
For file-based rails (e.g., ACH, RPPS), TabaPay schedules bulk file transmission and as defined by the networks.
API request batching refers to clients submitting large volumes of API calls simultaneously. This is not allowed, and is separate from network transmission that TabaPay sends.
Sandbox
TabaPay does implement rate limiting in the Sandbox Environment to maintain stable access for all clients. Clients should use Sandbox to validate integration behavior, not to simulate production-scale traffic. Any load testing should be planned and coordinated with TabaPay.
Production
On Production, TabaPay may block IP addresses generating excessive traffic.
Expected Client Behavior
| ✅ Do | ❌ Do Not |
|---|---|
| Send one transaction per request | Batch or bulk transactions |
| Distribute calls evenly throughout the day | Send large spikes or bursts |
| Maintain steady, consistent throughput | Use scheduled jobs |
| Implement exponential backoff retries (wait progressively longer between each retry) | Retrying requests immediately multiple times in a row. |
System Protection Behavior
TabaPay monitors traffic patterns and temporarily regulates excessive or disruptive request volumes to maintain overall system stability.
Excess Traffic Handling
If incoming traffic exceeds safe processing capacity, the platform will return the following error:
HTTP 503 – Service Unavailable
This indicates:
- Temporary saturation or spike protection
- Requests should slow down
- Client-side backoff is required
When to Contact TabaPay
Contact Support, or [email protected], if:
- Sustained 503 responses occur
- Planned volume increases
- You have new, high-throughput use cases
- Architecture changes impacting traffic
Simple Rule(s)
- Steady > Spiky (traffic)
- Real-time > Batch (API submission)
- 503 = Slow down and retry (API requests)