Rate Limits
Rate limiting rules, headers, and operational guidance for the Replenit Ingestion API.
Overview
Replenit applies rate limits to protect platform stability and ensure fair usage across tenants.
Rate limits are enforced per API key, across all tenants the key has access to.
All ingestion endpoints are subject to the same rate-limiting rules.
Default Rate Limits
| Limit Type | Value |
| Requests per minute | 100 |
| Requests per hour | 5,000 |
Limits apply to:
- Customers API
- Orders API
- Products API
- DELETE endpoints
How Rate Limits Are Calculated
- Each HTTP request counts toward the rate limit
- Batch size does not affect request count
- Requests across different tenants using the same API key share the same quota
Rate Limit Headers
Responses may include the following headers:
| X-RateLimit-Limit: 100 X-RateLimit-Remaining: 95 X-RateLimit-Reset: 1700000000 Retry-After: 30 |
Header definitions:
| Header | Description |
| X-RateLimit-Limit | Maximum requests allowed in the window |
| X-RateLimit-Remaining | Requests remaining in the current window |
| X-RateLimit-Reset | UNIX timestamp when the window resets |
| Retry-After | Seconds to wait before retrying |
429 Too Many Requests
When the rate limit is exceeded, the API returns HTTP 429.
Example response:
| { “success”: false, “message”: “Rate limit exceeded.”, “data”: {} } |
Retry Strategy
Only retry requests that fail with:
- 429 Too Many Requests
- 500 Internal Server Error
Recommended approach:
- Apply exponential backoff
- Respect the Retry-After header when present
- Add jitter to avoid synchronized retries
Example backoff sequence (seconds):
1 → 2 → 4 → 8 → 16
Batch Usage Recommendations
Batching reduces request volume and rate-limit pressure.
Recommended batch sizes:
| Entity | Batch Size |
| Customers | 100–500 |
| Orders | 50–200 |
| Products | 50–100 |
All endpoints expect arrays, even for single records.
Multi-Tenant Considerations
When an API key is authorized across multiple tenants:
- Rate limits are shared across all tenants
- High-volume ingestion for one tenant affects available capacity for others
For parallel multi-tenant ingestion:
- Use batching aggressively
- Serialize requests where possible
- Monitor remaining quota via headers
Handling Sustained High Volume
For sustained ingestion workloads:
- Prefer fewer, larger batches
- Avoid per-record requests
- Spread ingestion over time
- Monitor 429 responses and backoff behavior
If higher limits are required, contact your Replenit Customer Success Manager (CSM).
Common Rate-Limit Pitfalls
- Sending single-record requests in loops
- Retrying 400-series errors
- Ignoring Retry-After
- Running parallel ingestion jobs with the same API key
Observability
Rate-limit behavior can be observed via response headers.
Ingestion success and volume can be monitored in:
Replenit Dashboard → Data and Health
Access depends on tenant permissions.
Related Documentation
Error Responses
Replenit Ingestion API | Error Responses
Best Practices Guide
Replenit Ingestion API | Best Practices
Customers API
Replenit Ingestion API | Customers
Orders API
Replenit Ingestion API | Orders
Products API
Replenit Ingestion API | Products