Rate Limits

Env implements rate limiting to ensure the stability and reliability of our API for all users. This page explains our rate limiting strategy, limits by plan, and how to handle rate limit errors gracefully.

ℹ️

Need Higher Limits? If your use case requires higher throughput than our standard limits allow, contact our sales team to discuss a custom Enterprise plan.

Rate Limiting Overview

Rate limits are applied based on your API key and vary depending on your subscription plan. Limits are measured as:

Requests per minute (RPM) — Maximum requests allowed in a 60-second rolling window.
Requests per day (RPD) — Maximum requests allowed in a 24-hour period.
Burst capacity — Short-term allowance exceeding RPM for traffic spikes.

When you exceed a rate limit, Env returns an HTTP 429 Too Many Requests status code along with helpful headers to guide your retry strategy.

Rate Limits by Plan

Limit	Free	Pro	Enterprise
Requests per minute	30 RPM	500 RPM	5,000+ RPM
Requests per day	5,000 RPD	100,000 RPD	Unlimited
Burst capacity	50 requests	500 requests	Custom
Concurrent connections	2	10	Unlimited
Webhook delivery limit	100/day	10,000/day	Unlimited

⚠️

Burst vs. Sustained Throughput Burst capacity allows short spikes above your RPM limit, but sustained requests must stay within the RPM limit. Excessive bursting may trigger temporary throttling regardless of plan.

Response Headers

Every Env API response includes rate limit headers to help you monitor your usage and adjust your request patterns.

                    HTTP Response Headers
                    
X-RateLimit-Limit: 60# Maximum requests per minuteX-RateLimit-Remaining: 42# Remaining requests in current windowX-RateLimit-Reset: 1678901234# Unix timestamp when the limit resetsX-RateLimit-Reset-Relative: 32# Seconds until the window resets

Header Descriptions

Header	Description
`X-RateLimit-Limit`	The maximum number of requests allowed per minute for your plan.
`X-RateLimit-Remaining`	The number of requests remaining in the current rate limit window.
`X-RateLimit-Reset`	Unix timestamp (seconds) indicating when the rate limit window resets.
`X-RateLimit-Reset-Relative`	Seconds remaining until the current rate limit window resets.

Handling 429 Too Many Requests

When you exceed your rate limit, Env returns a 429 status code. The response body includes details about the error and a recommended retry-after time.

                    HTTP/1.1 429 Too Many Requests
                    
                
Content-Type: application/jsonRetry-After: 30X-RateLimit-Reset: 1678901234

{
  "error": {
    "type": "rate_limit_exceeded",
    "message": "You have exceeded your rate limit of 60 requests per minute.",
    "code": 429,
    "retry_after": 30,
    "docs": "https://env.com/docs/api/rate-limits"
  }
}
            

✅

Best Practice Always respect the Retry-After header. Implement exponential backoff with jitter to gracefully recover from rate limiting.

Recommended Strategies

Exponential Backoff

When you receive a 429 error, implement exponential backoff to retry your request:

                    JavaScript Example
                    
                
async functionmakeRequestWithBackoff(url, maxRetries = 5) {
  for (let i = 0; i < maxRetries; i++) {
    try {
      const response = awaitfetch(url);
      
      if (response.status === 429) {
        const retryAfter = parseInt(response.headers.get('retry-after')) || 1;
        const delay = retryAfter * 1000 + Math.random() * 1000; // Add jitterconsole.log(`Rate limited. Retrying in ${delay}ms...`);
        await newPromise(r => setTimeout(r, delay));
        continue;
      }
      
      return response.json();
    } catch (err) {
      if (i === maxRetries - 1) throw err;
    }
  }
}
            

Request Batching

Where possible, use our batch endpoints to combine multiple operations into a single request. This reduces overhead and helps you stay within rate limits.

Caching

Cache responses for non-critical data that doesn't change frequently. Use ETag headers to validate cache freshness without making full requests.

Endpoint-Specific Limits

Certain endpoints have additional rate limits due to higher computational costs:

POST /v1/analyze

10 RPM (analysis is resource-intensive)

POST /v1/export

5 RPM per day (large data exports)

POST /v1/webhooks

100 RPM (webhook creation)

GET /v1/compliance/reports

20 RPM (report generation)

Monitoring Your Usage

You can monitor your API usage and rate limit consumption in the Env Dashboard under Settings > API Keys > Usage Analytics. You'll receive email notifications when you reach:

80% of your daily limit
95% of your daily limit
100% of your daily limit (if you continue making requests with burst capacity)

📊

Usage API You can also programmatically check your usage via the GET /v1/usage endpoint, which returns real-time consumption metrics.

Need Help?

If you're consistently hitting rate limits despite optimizing your integration, or if you need a custom limit increase:

📧 Email: support@env.com
💬 Live Chat: Available in the dashboard for Pro and Enterprise plans
🎫 Community Forum: env.com/community

← Error Codes Webhooks →

Was this page helpful?