Rate Limits

The exit1.dev API enforces rate limits to ensure fair usage and platform stability.

Read Limits

“Per endpoint” means per route, not per check: GET /v1/public/checks/a and GET /v1/public/checks/b share one bucket, and so do toggling two different checks. This is on purpose. It keeps a script looping over many checks from turning into a burst of requests. These limits count every request, including writes.

To act on several checks in a row with an API key, space the calls a minute apart. For live status of every check, use /checks/status instead of fetching checks one by one.

Daily quotas are 24-hour windows that start with the first request counted against them, not calendar days.

Status Polling

GET /v1/public/checks/status has its own limits instead of the ones above, so a monitoring system can poll it every 10 to 30 seconds:

These requests do not count toward the daily quotas or the per-key limit of the other endpoints. The pre-authentication limit per IP still applies. Send If-None-Match with the last ETag to get a 304 when nothing changed.

Write Limits

Write endpoints (POST, PATCH, DELETE) have additional rate limits on top of the read limits:

Check Creation Limits

Creating checks is further limited to prevent abuse:

These are anti-abuse limits, not plan limits. They apply on every tier and are separate from your plan’s monitor cap.

OAuth (MCP) Sessions

Requests made with an OAuth access token from the hosted MCP server use a more generous profile, since agent sessions are interactive:

Rate Limit Headers

Responses include these headers:

On successful requests the headers describe the per-endpoint limit. On a 429 they describe the limit that was exceeded.

Exceeding Limits

When you exceed a rate limit, the API returns a 429 Too Many Requests response with a retryAfter field (seconds):

{
  "error": "Rate limit exceeded. Please try again later.",
  "retryAfter": 42
}

When a daily request quota is exceeded, the body also includes the quota and when it resets (epoch ms):

{
  "error": "Daily quota exceeded for this credential. Limit: 500 requests/day. The window resets 24 hours after it started (see quotaReset).",
  "quotaLimit": 500,
  "quotaReset": 1736985600000,
  "retryAfter": 31200
}

Rely on quotaReset (or retryAfter) for the actual reset time: the window ends 24 hours after it started.

Write limit 429s include retryAfter but not quotaLimit or quotaReset. The check creation limits return only an error message.

Best Practices

• Cache API responses locally when possible
• Implement exponential backoff when receiving 429 responses
• Honor Retry-After (or retryAfter in the body) instead of retrying blindly
• Monitor the RateLimit-Remaining header to stay within limits
• Spread requests evenly over time rather than bursting
• Use limit=100 on list requests to reduce the number of pages you fetch
• Poll /checks/status for live status instead of paging through the list
• Use ranges= on the stats endpoint to fetch several windows in one request
• Use idempotency keys when retrying failed create requests