Rate Limiting & Performance
To ensure the stability and availability of the payment engine for all merchants, fype enforces rate limits on API requests.Rate Limiting Architecture
fype uses an Atomic Token-Bucket algorithm. This ensures that limits are enforced consistently across all our API nodes.Limits by Environment
Note: Limits are applied per merchant account per environment.
Handling Rate Limit Errors
When you exceed the limit, the fype API returns a429 Too Many Requests response with the following JSON body:
Best Practices
- Implement Retries with Backoff: Use an exponential backoff strategy (e.g., 1s, 2s, 4s) when you receive a 429 error.
- Check the
Retry-AfterHeader: fype includes aRetry-Afterheader indicating the number of seconds to wait before retrying. - Optimize Bulk Operations: If you need to fetch many payments, use the Paginated List API with a higher
limitinstead of making multiple single-payment requests.
Performance Tips
1. Persistent Connections
Our SDKs (Node.js and Python) use connection pooling. Reusing the fype client instance across requests significantly reduces latency by avoiding repeated TLS handshakes.2. Regional Latency
fype’s core API is hosted in the Mumbai (India) region to provide the lowest possible latency for Indian payment gateways like Razorpay. For the best performance, host your backend in a nearby region.3. Asynchronous Webhooks
Do not block your webhook listener with heavy processing.- Recommended: Receive the webhook, verify the signature, enqueue a background job in your system, and return
200 OKimmediately. - Anti-pattern: Performing complex database migrations or sending multiple emails before responding to fype. This can lead to timeouts and unnecessary retries from fype’s worker.