What is a good API rate limit for public APIs?

A good API rate limit for public APIs typically ranges from 60-100 requests per minute for unauthenticated users and 1,000-5,000 requests per minute for authenticated users with API keys. The optimal limit balances infrastructure protection with legitimate use cases, enabling developers to build functional applications while preventing abuse that could degrade service for all users.

However, there’s no universal “correct” rate limit. The right threshold depends on your API’s computational cost per request, infrastructure capacity, business model, and target user base. Successful public APIs implement tiered limits that encourage user progression from free experimentation to paid production usage.

What Good Rate Limits Do and Do Not Do

Effective rate limits achieve specific objectives without unnecessary restrictions:

Prevent Infrastructure Overload: Limits protect your servers, databases, and downstream services from excessive load that could cause slowdowns or outages affecting all users.

Enable Legitimate Use Cases: Developers should build functional applications, test integrations, and serve reasonable user bases without constantly hitting limits during normal operation.

Provide Clear Upgrade Paths: Free tier limits should be restrictive enough to encourage upgrades while generous enough for developers to evaluate your API and build proof-of-concept applications.

Reflect Actual Costs: Rate limits should align with computational resources requests consume. Expensive AI inference endpoints need stricter limits than simple data lookups.

Do Not Copy Competitors Blindly: Copying competitors’ rate limits ignores your unique infrastructure, cost structure, and business model. Set limits based on your capabilities and strategy.

The One Critical Principle Worth Following

Implement multiple rate limit layers rather than a single blanket restriction. Combine per-second, per-minute, and per-day limits to handle different abuse scenarios. A malicious script making 10,000 requests in 10 seconds gets blocked by per-second limits even if daily quota is 100,000. A legitimate application spreading requests evenly uses daily quota efficiently without triggering burst limits.

Apply endpoint-specific limits where expensive operations (bulk exports, AI processing, complex database queries) have stricter restrictions than simple read operations (fetching single records, health checks). This multi-layered approach blocks abuse while accommodating legitimate use patterns.

Common Rate Limit Ranges by User Type

Unauthenticated/Anonymous Requests

Conservative: 10-30 requests per minute, 100-500 requests per day. Used by APIs prioritizing security and infrastructure protection.

Moderate: 60-100 requests per minute, 1,000-5,000 requests per day. Balances accessibility with protection, allowing developers to experiment without registration.

Liberal: 100-300 requests per minute, 10,000-50,000 requests per day. Emphasizes developer experience and API adoption.

Free Tier (Authenticated with API Key)

Entry Level: 1,000-5,000 requests per day, 60-120 requests per minute. Supports learning, development, and small personal projects.

Developer Friendly: 10,000-50,000 requests per day, 100-500 requests per minute. Enables building and testing production-ready applications.

Growth Oriented: 100,000-250,000 requests per day, 1,000-2,000 requests per minute. Very generous free tier that builds loyalty and captures market share.

Paid/Premium Tiers

Basic Paid: 100,000-500,000 requests per day, 2,000-5,000 requests per minute. Entry-level paid tier for small to medium applications ($10-50/month).

Professional: 1,000,000-5,000,000 requests per day, 10,000-20,000 requests per minute. Supports established applications with substantial user bases ($100-500/month).

Enterprise: 10,000,000+ requests per day, 50,000-100,000 requests per minute, or custom/unlimited. Large-scale production applications with negotiated pricing.

Endpoint-Specific Rate Limiting

Different operation types warrant different limits:

Read Operations (GET): Higher limits (1,000-5,000 requests/minute) since reads typically consume fewer resources and scale better with caching.

Write Operations (POST/PUT/DELETE): Lower limits (100-500 requests/minute) since writes modify state, require database transactions, and invalidate caches.

Bulk Operations: Strictest limits (10-50 requests/minute) for bulk import/export endpoints processing thousands of records per request.

Authentication Endpoints: Very strict (5-10 attempts per 15 minutes) to prevent brute force attacks while allowing legitimate retry attempts.

AI/ML Inference: Conservative limits (10-100 requests/hour) for endpoints running machine learning models due to high computational costs, like OpenAI API integrations.

Real-World API Examples

Learning from established platforms:

GitHub API: 5,000 requests/hour for authenticated users, 60 requests/hour for unauthenticated. Strong authentication incentive with generous authenticated limits.

Stripe API: 100 requests/second in test mode, variable in production based on account history. Focuses on burst protection over daily limits.

Google Maps API: $200/month free credit (approximately 28,000 map loads), then pay-per-use. Credit-based rather than hard rate limits.

Twitter API: Extremely restrictive on free tier (1,500 requests/month), prioritizing monetization over developer experience.

Implementation Best Practices

Start Conservative: Begin with stricter limits and relax based on observed usage patterns rather than starting permissive and tightening when problems occur.

Monitor Extensively: Track 429 error rates, quota utilization, and usage patterns to identify if limits are too restrictive or generous. Our guide on implementing rate limiting covers monitoring strategies.

Include Response Headers: Always return X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset headers so developers can track consumption programmatically.

Document Clearly: List all rate limits prominently in API documentation following OpenAPI specification standards.

Use Multiple Time Windows: Implement per-second limits (prevent burst attacks), per-minute limits (control sustained rates), and per-day limits (overall quotas aligned with billing).

Security Integration

Tie rate limits to authentication for better control:

OAuth 2.0 Integration: Extract user identity from OAuth tokens and apply user-specific limits rather than just IP-based throttling.

JWT Claims: Use JWT token claims to encode subscription tier or special permissions directly in authentication tokens.

API Key Tiers: Associate different rate limits with different API key types (development keys, production keys, enterprise keys).

For comprehensive security guidance, review our article on securing APIs with OAuth 2.0 and JWT.

Why Getting Rate Limits Right Matters

Well-designed rate limits protect your infrastructure while enabling your API to thrive. Too restrictive limits frustrate developers, reduce adoption, and push users to competitors. Too generous limits inflate infrastructure costs and subsidize users who should be paying.

The best public APIs treat rate limiting as product design, not just technical implementation. Limits should enable your business model, reflect your value proposition, and scale naturally through tiered pricing strategies. Whether building REST APIs, GraphQL services, or implementing API versioning, rate limits form the foundation of sustainable API delivery.