Atlas Enterprise is priced at $99 a month, which includes 10,000,000 platform requests a month, then $1 per 100,000 requests after that. Atlas’s features page describes this as usage-based metered pricing. This article explains how to think about it and how to plan.
Why metered pricing
Enterprise is the tier where Atlas becomes the backend for your own applications — customer portals, dashboards, mobile apps — through the Atlas API Client and Atlas SDK. Usage varies enormously between businesses: a small internal dashboard makes far fewer requests than a busy customer portal. A generous included allowance with a low per-request rate above it keeps the base price predictable while scaling fairly with use.
The arithmetic
Overage is billed in blocks of 100,000 requests above the included 10,000,000.
| Monthly requests | Over the allowance | Overage | Total |
|---|---|---|---|
| 4,000,000 | — | $0 | $99 |
| 10,000,000 | — | $0 | $99 |
| 12,000,000 | 2,000,000 | $20 | $119 |
| 25,000,000 | 15,000,000 | $150 | $249 |
How much is 10 million?
Ten million requests a month is roughly 330,000 requests a day, or about 3.8 requests every second, around the clock. For most small and mid-sized businesses, that’s comfortably more than their applications need. Even a portal where 1,000 customers each trigger 100 requests a day uses about 3 million requests a month.
Estimating your usage
A rough estimate is enough to plan:
- List your applications — portal, dashboard, mobile app, integrations.
- Estimate daily active users for each.
- Estimate requests per user per day — how many screens they load and actions they take, and how many Atlas calls each makes.
- Multiply and add up, then multiply by 30 for a month.
- Add integrations — scheduled syncs or imports that call Atlas on their own.
Compare the total with the 10,000,000 allowance.
Habits that keep usage efficient
- Fetch what a screen needs, once. Use search with sensible limits rather than fetching records one by one.
- Cache stable information. Schemas and classifications change rarely; applications don’t need to re-fetch them on every screen.
- Avoid tight polling loops. Poll at a sensible interval, or refresh when the user acts.
- Batch background jobs and run them at a steady pace rather than in bursts.
- Watch integrations. A misconfigured sync is the most common source of surprise usage in any metered API.
What doesn’t change
Metered usage applies to Enterprise’s platform requests. Basic remains free, Advanced remains $5 a month per subscribing account, and Enterprise includes everything in both. See current pricing for full details, including exactly how requests are counted.
Where requests come from
Understanding what drives usage makes estimates easier. In a typical deployment, requests come from:
- Interactive screens in your own applications — each screen load reads some records.
- Actions people take: creating, updating or archiving records.
- Background integrations — scheduled syncs with other systems.
- Document generation triggered programmatically.
- Process automation — starting runs, satisfying directives, reading run state.
Interactive screens usually dominate early on; integrations often become the biggest consumer as you automate more.
A worked estimate
A property services business builds a customer portal and an internal dashboard:
| Source | Volume | Requests each | Monthly requests |
|---|---|---|---|
| Portal: 800 customers, 4 visits a month | 3,200 sessions | 25 | 80,000 |
| Dashboard: 12 staff, daily use | 250 sessions/day × 30 | 40 | 300,000 |
| Nightly sync with scheduling system | 30 runs | 2,000 | 60,000 |
| Document generation | 600 documents | 3 | 1,800 |
| Total | ≈ 442,000 |
That’s well under the included 10,000,000. Most small and mid-sized deployments look like this; the allowance becomes relevant at a much larger scale or with unusually chatty integrations.
Keeping an eye on usage
- Instrument your own applications. Counting the calls your code makes is the earliest warning of a change in pattern.
- Review after each release. A new screen that loads more data can change usage noticeably.
- Watch scheduled jobs. A sync that starts re-reading everything nightly instead of only changes is the classic cause of a jump.
- Set your own alert threshold well below the allowance, so you have time to react.
Frequently asked questions
Is the allowance per organization? Enterprise is listed at $99 a month including 10,000,000 platform requests a month, then $1 per 100,000. See pricing for the current terms.
Does using the Atlas interface consume the allowance? The allowance is described in terms of platform requests; the pricing page is the authority on exactly what’s counted.
What happens if I go over? Overage is charged at $1 per 100,000 requests — a predictable, linear cost rather than a cut-off.
Can I reduce usage without changing features? Usually yes: cache stable data, fetch lists rather than individual records, and avoid tight polling.
Planning for growth
Request volume tends to grow with customers and with features. A simple way to stay ahead:
- Re-estimate when you add an application or a significant new screen.
- Re-estimate when customer numbers change materially, since portal usage scales with them.
- Treat integrations as their own line item, because they’re the least visible and the fastest to grow.
- Keep headroom. Planning to sit at 90% of the allowance leaves no room for a busy month.
Because overage is linear — $1 per 100,000 requests — exceeding the allowance isn’t a cliff. It’s a cost you can predict and budget for.
