Usage Limits

Reloop enforces rate limits on API requests to ensure stability and fair usage across all organizations. Limits are applied per organization and tracked using a sliding window counter backed by Redis.

If a limit is exceeded, the API returns a 429 Too Many Requests response with a Retry-After header indicating how many seconds to wait.

Management Endpoint Limits

Management endpoints cover everything outside of email sending — domains, contacts, channels, groups, properties, API keys, and templates. Each endpoint category has its own independent limit.

Domain Service

Contacts Service

Channels Service

Groups Service

Contact Properties Service

API Keys Service

Preferences Service

---

Email Sending Limits

The email sending endpoint (/api/mail/v1/send) uses a multi-layer rate limiting strategy. All five layers are checked in parallel — if any single layer is exceeded, the request is rejected.

When a sending request is rate limited, the error response tells you which layer was exceeded:

{
  "message": "Too Many Requests",
  "why": "Rate limit exceeded on the organization layer. You have sent too many requests in the current time window.",
  "fix": "Please wait 42 seconds before retrying, or contact support to increase your limits."
}

---

Rate Limit Headers

Every API response includes headers indicating your current rate limit status. The specific headers vary slightly between management and sending endpoints.

Management Endpoints

Email Sending Endpoints

---

Best Practices

• Monitor headers proactively. Check X-RateLimit-Remaining before it reaches zero to avoid disruptions.
• Implement exponential backoff. When you receive a 429, wait for the duration specified in Retry-After, then retry with increasing delays if the limit is still exceeded.
• Batch where possible. Use list endpoints with pagination instead of fetching resources one at a time.
• Separate read and write traffic. Read operations (list, get) generally have higher limits than write operations (create, update, delete).