Rate Limiting

Dictionary API enforces rate limits to ensure stability, fairness, and consistent performance for all developers. This guide explains how limits are calculated, how to monitor your usage, and best practices for handling throttled requests.

ℹ️

Rate limits are applied per API key, not per IP address. Generate multiple keys in your dashboard if you need to distribute limits across different services.

Limit Tiers

Rate limits vary based on your subscription plan. All limits reset automatically on a rolling basis.

Plan	Requests / Minute	Requests / Day	Concurrent Connections	Burst Allowance
Free	30	5,000	2	10
Pro	120	100,000	10	50
Enterprise	1,000+	Unlimited	50+	Custom

Monitoring Your Usage

Every API response includes standard rate limit headers so you can programmatically track your quota and adjust request pacing accordingly.

Response Headers

X-RateLimit-Limit: 120
X-RateLimit-Remaining: 84
X-RateLimit-Reset: 1718934567

X-RateLimit-Limit – The maximum number of requests allowed per minute for your plan.
X-RateLimit-Remaining – How many requests you have left in the current rolling window.
X-RateLimit-Reset – Unix timestamp when your quota resets completely.

Handling Throttled Requests

When you exceed your rate limit, the API returns an HTTP 429 Too Many Requests status. The response includes a Retry-After header indicating how many seconds to wait before making another request.

⚠️

Continuing to send requests while receiving 429 responses may result in temporary key suspension to protect our infrastructure.

Error Response Format

                HTTP 429 JSON Response
                
            
{
  "error: {
    "code: "rate_limit_exceeded",
    "message: "You have exceeded your rate limit. Please wait and retry later.",
    "retry_after: 12,
    "limit: 120,
    "remaining: 0
  }
}

Best Practices

1. Implement Exponential Backoff

Never poll aggressively after a 429. Use exponential backoff with jitter to resume requests smoothly.

                JavaScript Example
                
            
async function fetchWithBackoff(url, retries = 5) {
  try {
    const res = await fetch(url);
    if (res.status === 429) {
      const retryAfter = res.headers.get('Retry-After') || 2;
      console.log(`Rate limited. Retrying in ${retryAfter}s`);
      await new Promise(r => setTimeout(r, retryAfter * 1000));
      return fetchWithBackoff(url, retries - 1);
    }
    return res.json();
  } catch (err) {
    if (retries > 0) return fetchWithBackoff(url, retries - 1);
    throw err;
  }
}

2. Cache Responses

Dictionary definitions rarely change. Cache successful responses locally or via CDN to reduce API calls significantly. Recommended TTL: 24–72 hours.

3. Queue Bulk Requests

If processing large word lists, use a job queue (Redis, SQS, etc.) with controlled concurrency matching your tier's limits. Parallelize safely, but never exceed the per-minute ceiling.

4. Monitor Dashboard

Set up usage alerts in your Dictionary Developer Dashboard. We recommend configuring notifications at 75%, 90%, and 100% of your daily quota.

🚨

Need Higher Limits? Enterprise customers can request custom rate limits tailored to their traffic patterns. Contact our sales team to discuss your requirements.

Last updated: November 2025 • API Changelog