This page explains how rate limiting works in the Fintegence Partner API and how to build a client that behaves safely under traffic constraints.300 requests per minute per unique IP address. This is sufficient for most integrations while helping keep the service fast and reliable for all partners.
Why Rate Limiting Matters#
Rate limiting is not only a restriction mechanism. It is a core reliability and protection feature.Security: Helps protect the API against abusive traffic patterns, brute-force attempts, and denial-of-service behavior.
Performance: Preserves stable response times across all integrations, even under elevated traffic.
Fair Usage: Prevents a single client from monopolizing shared API resources.
Stability: Reduces the risk of service degradation caused by bursts, bots, or inefficient polling loops.
How It Works#
The system tracks request volume per source IP address in real time.API responses include headers that help you monitor your current usage within the active rate limit window.| Header | Description | Example |
|---|
X-RateLimit-Limit | Total number of requests allowed in the current time window. | 300 |
X-RateLimit-Remaining | Number of requests remaining in the current window. | 241 |
X-RateLimit-Reset | UTC epoch timestamp, in seconds, when the current quota resets. | 1678886400 |
Handling Exceeded Limits (429 Too Many Requests)#
When the limit is exceeded, the server rejects the request with HTTP 429 Too Many Requests. You should always honor the Retry-After header before retrying.Example 429 Handling Model
Header: Retry-After: 60A typical 429 response may include error details similar to the following:{
"error": "Rate limit exceeded",
"message": "You have exceeded the maximum number of requests allowed (300 requests/min). Please try again later.",
"retry_after": 60,
"limit": 300,
"window": "1 minute"
}
Best Practices for Integration#
A reliable client should anticipate rate limiting and react gracefully.1. Proactive Monitoring#
Do not wait for a 429 response. Monitor the X-RateLimit-Remaining header and slow down before the limit is exhausted.2. Intelligent Retry Logic#
When a 429 response occurs, use the Retry-After header and apply retry logic carefully. Exponential backoff is recommended for bursty or repeated failures.3. Avoid Aggressive Polling#
Polling loops for asynchronous operations should be rate-aware. If you are tracking exchanges, withdrawals, orders, or transfers, prefer webhooks over tight polling intervals.4. Batch Thoughtfully#
Where possible, avoid unnecessary request bursts. Reuse previously fetched data, debounce user-triggered refresh actions, and avoid parallel request storms from the same IP.If your integration is expected to generate consistently high request volume, contact the team to discuss whether your traffic profile requires a different operational setup.
