---
title: Usage Limits
description: Understand rate limits and quotas for the Reloop API.
---
> For the complete documentation index, see [llms-docs.txt](/llms-docs.txt) or the site index [llms.txt](/llms.txt). Full docs corpus: [llms-full-docs.txt](/llms-full-docs.txt). Prefer markdown URLs (append `.md`) for agent consumption. Product skill: [skill.md](/skill.md).


Reloop enforces rate limits on API requests to ensure stability and fair usage across all organizations. Limits are tracked with fixed-window counters 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.

## Baseline Limit

Every API endpoint shares a baseline of **600 requests per 60 seconds per client**. A client is identified by its API key, then its dashboard session, then its IP address for unauthenticated requests. The budget is shared across all services, so calls to `/api/domain`, `/api/contacts` and `/api/logs` draw from the same bucket.

The endpoint-specific limits below apply on top of the baseline, and the stricter one wins. Self-hosted deployments can change the baseline with the `API_RATE_LIMIT_MAX` and `API_RATE_LIMIT_WINDOW_SECONDS` environment variables.

## 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

| Operation | Limit | Window |
|-----------|-------|--------|
| Create Domain | 10 requests | 60s |
| Update Domain | 10 requests | 60s |
| Delete Domain | 10 requests | 60s |
| Verify DNS | 10 requests | 60s |

### Contacts Service

| Operation | Limit | Window |
|-----------|-------|--------|
| List Contacts | 60 requests | 60s |
| Get Contact | 60 requests | 60s |
| Create Contact | 200 requests | 60s |
| Update Contact | 30 requests | 60s |
| Delete Contact | 30 requests | 60s |

### Channels Service

| Operation | Limit | Window |
|-----------|-------|--------|
| List Channels | 60 requests | 60s |
| Get Channel | 60 requests | 60s |
| Create Channel | 30 requests | 60s |
| Update Channel | 30 requests | 60s |
| Delete Channel | 30 requests | 60s |

### Groups Service

| Operation | Limit | Window |
|-----------|-------|--------|
| List Groups | 60 requests | 60s |
| Get Group | 60 requests | 60s |
| Create Group | 30 requests | 60s |
| Update Group | 30 requests | 60s |
| Delete Group | 30 requests | 60s |
| Add Contact to Group | 30 requests | 60s |
| Remove Contact from Group | 30 requests | 60s |

### Contact Properties Service

| Operation | Limit | Window |
|-----------|-------|--------|
| List Properties | 60 requests | 60s |
| Create Property | 30 requests | 60s |
| Update Property | 30 requests | 60s |
| Delete Property | 30 requests | 60s |

### API Keys Service

| Operation | Limit | Window |
|-----------|-------|--------|
| Create API Key | 10 requests | 60s |
| Update API Key | 30 requests | 60s |
| Delete API Key | 20 requests | 60s |
| Rotate API Key | 20 requests | 60s |
| Enable / Disable API Key | 30 requests | 60s |

### Preferences Service

| Operation | Limit | Window |
|-----------|-------|--------|
| Generate Token | 30 requests | 60s |
| Update Preference | 30 requests | 60s |

---

## 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. The organization daily layer applies only to plans with a daily sending limit (Free); Pay as you go, Pro and higher plans have no daily cap.

| Layer | Limit | Window | What It Protects |
|-------|-------|--------|-----------------|
| IP | 20 requests | 60s | Prevents brute-force from a single source. |
| User | 50 requests | 60s | Stops abuse from a single user within an organization. |
| Organization | 100 requests | 60s | Prevents runaway integrations per tenant. |
| Organization Daily | 5,000 requests | 24h | Daily cap per organization on the Free plan. Not applied to Pay as you go, Pro and higher. |
| Global | 500 requests | 60s | Protects infrastructure from DDoS. |

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

```json
{
  "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, including errors such as `401` and `404`, includes rate limit headers. When an endpoint has its own stricter limit, the headers describe that limit.

| Header | Description | Example |
|--------|-------------|---------|
| `ratelimit-limit` | Maximum requests allowed in the current window. | `600` |
| `ratelimit-remaining` | Requests remaining in the current window. | `587` |
| `ratelimit-reset` | Seconds until the window resets (a countdown, not a timestamp). | `42` |
| `retry-after` | Seconds to wait before retrying (only on `429`). | `42` |

`X-RateLimit-Limit`, `X-RateLimit-Remaining` and `X-RateLimit-Reset` carry the same values for older clients. Email sending responses also include `x-reloop-daily-quota` and `x-reloop-monthly-quota` with your used send counts.

---

## Best Practices

- **Monitor headers proactively.** Check `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).