Request-based pricing explained (APIs, CDN, and messaging)
Start with a calculator if you need a first-pass estimate, then use this guide to validate the assumptions and catch the billing traps.
This is the billing page for request fees. Convert monthly counts into per-10k or per-1M pricing without losing track of the billable units.
If you still need to define what counts as a request or how many requests to model, go back to the request boundary guide before you finalize the price.
Use this page when the math is the job
- Use this guide when you need requests/month, request-class splits, or billable-unit mapping.
- Stay here if the issue is pricing math across products, not one messaging system's delivery behavior.
- Move back to parent guides when the bigger workload model is still unclear.
Request pricing quick model
- Requests/month: baseline volume from logs or metrics.
- Price per unit: per 10k or per 1M depending on provider.
- Retry factor: include retries and bot traffic multipliers.
- Peak profile: keep baseline and incident windows separate.
Map the workload to the billable request type
"Request pricing" is not one uniform billing model. Providers can bill origin requests, API calls, inspected WAF requests, queue deliveries, or event invocations. Before doing the math, write down the exact billable unit in one sentence so the estimate matches the pricing page.
- API: endpoint calls, auth checks, and internal retries can all count.
- CDN: request fees usually follow edge hits, while miss rate changes origin-side costs.
- Messaging: deliveries and fan-out often matter more than publishes.
- Security: WAF or bot filtering can bill inspected requests during attack spikes.
When request pricing is not the main driver
- Bandwidth: CDN or API responses can dwarf request fees.
- Compute: per-request compute or serverless GB-seconds can dominate.
- Logs: per-request logs and scans add a second bill.
- Storage: retention or snapshots can be larger than request costs.
The biggest mistake on this page is confusing billing math with workload structure
This page should solve the generic math problem: what counts as a request, how units are priced, and how retries and traffic shape change totals. It should not replace parent pages that explain why the workload behaves that way.
1) Get or estimate requests/month
- Best: provider analytics, logs, or billing exports (measured request counts).
- Fallback: convert from RPS with RPS to Monthly Requests.
If you do not have request metrics yet, estimate from business events: signups, orders, or jobs per month multiplied by requests per event.
Build the estimate by traffic shape, not by one average
- Baseline window: normal traffic and normal retries.
- Peak window: launches, seasonal surges, or batch jobs.
- Incident window: dependency failures, bot spikes, and retry amplification.
A request-priced system can look cheap on an average day and still produce a painful bill during a retry storm. Keep at least a baseline and peak scenario, and add an incident case when the service is public-facing.
2) Confirm request units (per 10k vs per 1M)
Pricing pages often quote "$ per 10k" or "$ per 1M". If you multiply by the wrong unit, the estimate can be off by 100x.
3) Split by request class (when providers have tiers)
Many services have more than one request class (for example: cached vs uncached, read vs write, standard vs advanced). Do not blend them if prices differ materially.
- API: reads vs writes, auth-heavy endpoints, and retry-prone endpoints.
- CDN: cached hits vs origin requests (cache miss rate changes origin cost).
- Messaging: publishes vs deliveries (fan-out and retries multiply deliveries).
Service-specific notes: API gateways also bill internal service-to-service traffic; CDNs can have request fees even when bandwidth is low; messaging costs scale with deliveries, not just publishes.
Service-specific request drivers
- API: auth checks, validation, and internal fan-out calls.
- CDN: cache key fragmentation and TTL policies that change request volume.
- Messaging: delivery fan-out and retries during failures.
- Security: bot spikes or attack traffic can multiply requests.
What counts as a request varies
- SDK batch operations can be billed as multiple requests.
- WebSocket or streaming messages may count as request units.
- Health checks and HEAD calls can be billable even with zero payload.
4) Estimate request cost
- API requests: API request cost calculator
- CDN requests: CDN request cost calculator
- For CDNs, also model bandwidth with CDN bandwidth cost
Worked estimate template (copy/paste)
- Requests/month = baseline + peak (include retries)
- Price unit = per 10k / 100k / 1M (write it down explicitly)
- Class split = cached vs uncached (or read vs write) if pricing differs
- Cost = sum(class_requests / unit x price_per_unit)
Mini examples by service type
- API: MAU x sessions/user x requests/session.
- CDN: page views x assets per page + API calls.
- Messaging: publishes x matched subscribers x retry factor.
5) Validate (avoid surprise multipliers)
- Identify retry loops and timeouts. These can multiply API request volume and add transfer.
- Separate human traffic from bots. WAF/bot protection costs can track request spikes.
- If you're behind a CDN, cache miss rate affects origin request volume even if CDN request counts stay high.
Common pitfalls
- Using a single monthly average and ignoring peak windows (marketing events and incidents).
- Not splitting endpoints: a heavy endpoint can dominate requests and transfer.
- Forgetting internal traffic: service-to-service calls can be larger than user traffic.
- Assuming retries are rare (they often become "normal" under throttling or dependency issues).
- Forgetting which product counts publishes, deliveries, or inspected requests as the billable unit.
Checklist for a reliable estimate
- Define billable request types in one sentence.
- List the top three request sources (user, internal, bots).
- Run baseline, peak, and incident scenarios.
- Validate against a week of logs or billing data.
Sources
Related reading
If the issue is still how publishes turn into deliveries and retries, go back to messaging costs before continuing with request math.