Rate Limits
Learn about the rate limits for the Encatch Web and Mobile SDKs and the server-to-server Admin API
We enforce rate limits to prevent abuse and ensure our APIs are used fairly by all users. There are two independent sets of limits:
- SDK rate limits apply to traffic from our Web SDK and Mobile SDKs (feedback fetching and submission), authenticated with a publishable SDK key.
- Admin API rate limits apply to server-to-server calls made with an admin API key. Jump to Admin API rate limits.
Rate Limit Enforcement
Rate limits are applied per project, per contact/user ID, and per IP address. User and IP limits apply within each project. The following table shows the limits for each environment type:
Production projects
| Limit scope | Requests per minute |
|---|---|
| Per project | 40,000 |
| Per contact / user ID | 100 |
| Per IP address | 400,000 |
Sandbox projects
Sandbox projects are designed to let you test during implementation and throughout ongoing project development. They are not intended for production use. Their limits are set to avoid exhausting our systems while still supporting development workflows.
| Limit scope | Requests per minute |
|---|---|
| Per project | 50 |
| Per contact / user ID | 25 |
| Per IP address | 250,000 |
Rate Limit Headers
When you make requests to the API, you'll receive rate limit information in the response headers:
X-RateLimit-Limit: The maximum number of requests allowed per time windowX-RateLimit-Remaining: The number of requests remaining in the current time windowX-RateLimit-Reset: The time at which the current rate limit window resets (Unix timestamp in seconds)
Handling Rate Limits
When you exceed the rate limit, you'll receive a 429 Too Many Requests response. You should:
- Wait for the rate limit window to reset
- Implement exponential backoff in your application
- Consider caching responses to reduce API calls
The limits above apply to publishable SDK key traffic only. Admin API keys have their own quotas, described next.
Admin API rate limits
Admin API traffic is limited per minute on two independent scopes: per project (shared by every admin key on the project) and per API key. A request counts against both, and if either is exhausted the API returns 429 Too Many Requests.
Whether a project is Sandbox or Production is fixed when the project is created — see Sandbox Environment.
Sandbox projects
| Limit scope | Requests per minute |
|---|---|
| Per project (all admin keys combined) | 500 |
| Per API key | 100 |
Production projects
| Limit scope | Requests per minute |
|---|---|
| Per project (all admin keys combined) | 10,000 |
| Per API key | 4,000 |
The tighter remaining quota wins. In sandbox, one key reaches its 100/min limit before the 500/min project limit. In production, one key reaches 4,000/min before the project reaches 10,000/min.
Admin API responses include the same X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset headers, and you should handle 429 the same way: wait until X-RateLimit-Reset, retry with exponential backoff, and spread traffic across keys only while you are under the project cap. Admin endpoints are listed under Admin API Reference in the docs sidebar.
Was this page helpful?
