Rate limits

​

Overview

Rate limits protect Atlas from noisy clients while keeping public civic data available. The important design choice is not just “how many requests can I send?” It is “what access pattern matches the workflow?”

​

Choose the right access pattern

Unauthenticated requests always use the public limit even if the user also has a paid account. Authenticate recurring integrations.

​

Current limits

Use the generated reference and pricing page for exact plan details when limits change. An Authorization or X-API-Key header only receives authenticated limits after Atlas verifies it. Invalid or forged credential headers are treated as anonymous traffic after the pre-auth protection bucket.

​

Build with limits in mind

• Cache place, taxonomy, and source responses when the source data does not need to be live.
• Page through results deliberately instead of requesting every record.
• Preserve entity ids and source ids so you can refresh specific records later.
• Use coverage endpoints to decide where more API calls are worth spending.
• Back off on 429 instead of retrying in a tight loop.

​

Handling 429

A rate-limited response means the request was understood but the client has exhausted its current window. When that happens:

1. Stop the current loop.
2. Check rate-limit headers when present.
3. Use Retry-After or wait until X-RateLimit-Reset when present.
4. Cache the successful responses you already received.
5. Authenticate or upgrade only if the workflow truly needs higher volume.

​

When to redesign instead of upgrade

Higher limits are not a substitute for a better workflow. Redesign the integration if it repeatedly:

• Refetches the same actors without using ids.
• Drops sources and has to rediscover evidence.
• Crawls all places to answer one local question.
• Starts discovery runs without a review plan.
• Polls completed runs forever.

​

Next steps