Review the work admitted by one request before counting requests per minute. An authenticated export, search, report build or provider call may consume significant compute or money even when it is called slowly. For one operation, map its caller, maximum input size, fan-out, concurrency, queue depth, third-party cost and cancellation behavior. Then check where each bound is enforced and which identity or account shares the budget. A rate limit is useful only if the expensive work is rejected or deferred before it consumes the resource it is meant to protect. If normal workload and provider costs are unknown, record a provisional limit and the measurements needed to tune it. OWASP's API4:2023 resource-consumption guidance explicitly includes page size, batched work, execution resources, request frequency and third-party spending limits.
Start with one illustrative export
Illustrative service and numbers only; no traffic was generated. Northstar Analytics offers POST /exports to authenticated account users. A request can select a date range and output format. The service queues a worker, scans records, renders a file and stores it for download. Its gateway applies a generic limit of 100 requests per minute per IP address. A single broad export may run for 20 minutes and use a paid transformation service. The platform engineer asks whether the gateway limit protects the account and the shared worker pool.
It probably does not answer the whole question. Two users behind one office IP may be blocked unfairly, while one user can change network address or submit expensive requests just under the frequency threshold. More decisively, the gateway counts calls, not how many records each call scans, how many jobs run concurrently or what the provider charges. The OWASP REST Assessment Cheat Sheet directs reviewers to exercise expensive operations and check the cost of a single request, as well as what key the limit uses.
Build a budget card before choosing a number
Ask the service owner and finance or provider owner for a normal-use baseline, not a guessed “industry standard.” Record one card for each costly operation:
| Budget dimension | Northstar example for review | Evidence to request |
|---|---|---|
| Request identity | Signed-in user and current account; service jobs bound to initiating account | Gateway identity mapping and job record |
| Work per request | Date window and record count bounded before queue admission | Query plan and server-side validation |
| Parallel work | At most two running exports per account, illustrative target | Atomic admission/lease logic and worker capacity |
| Queued work | Finite pending jobs per account and globally | Queue admission and expiry policy |
| Provider cost | Estimated units reserved before provider call; settled afterward | Price schedule, usage ledger, hard cap or alert |
| Time and storage | Worker deadline, output-size cap, retention and cancellation | Worker configuration and cleanup path |
| Response to excess | Clear rejection or deferred admission before job launch | API response and job-state trace |
The figures in this card are not recommended settings. The right thresholds depend on tenant size, legitimate burst behavior, service objective, maximum loss the business will accept and the provider's billing model. Document who may change them and how a customer can recover from a rejected but legitimate export.
Follow the request through each admission point
1. Identify the truly expensive action. Draw the path from request parsing to authentication, authorization, query planning, queue write, worker launch, provider call and result storage. Note whether the gateway returns 202 Accepted before work starts. The client response does not reveal whether a later worker can multiply cost. If an export calls other APIs, include those retries and batch sizes in the work estimate.
2. Bound one request. Check maximum date range, page size, number of selected fields, output bytes, query timeout and provider units. Confirm the server computes these bounds, including for empty or omitted parameters. A valid page_size of one million or a batch containing thousands of subrequests can bypass a pure frequency cap. OWASP API4 names these per-request limits separately from rate limiting.
3. Choose the budget key. For an authenticated operation, decide whether limits apply per user, API key, account, operation and global pool. A per-IP edge limit may still help with anonymous floods, but it cannot be the only control for paid account work. Confirm account switching, token refresh, multiple keys and worker retries do not reset a cost budget unintentionally. Shared accounts require fair usage across members without trusting a client-provided tenant ID.
4. Make admission atomic enough for the resource. If two requests arrive together, can each see one free slot and both launch? Look for a conditional reservation, transactional count or equivalent concurrency control, plus release on success, failure, timeout and cancellation. A dashboard counter updated after launch is observation, not admission control. The OWASP Denial of Service Cheat Sheet recommends cheap validation before expensive work and planning across application, session and network layers.
5. Confirm failure behavior. If the limiter's backing store is unavailable, does the expensive operation launch without a budget? If the queue is full, does the API return a durable job that will never run? If a worker crashes, does its reservation expire without letting old and replacement workers both spend? These cases determine whether the limit survives real operating conditions.
6. Observe safely. In a controlled environment, with the service owner and provider sandbox, inspect synthetic requests at the accepted boundary and just beyond it. Record admitted job count, peak concurrency, estimated and actual units, queue depth, rejection timing and caller-visible response. Do not generate load against production or incur paid calls simply to prove a draft point. A configuration file can support a source conclusion; it does not prove that the production route uses that configuration.
Turn a workload sheet into a provisional budget
The following units, thresholds and outcomes are invented design inputs, not performance measurements or recommended defaults. Northstar's owner chooses a daily account allowance of 100 transformation units, two active exports, four waiting exports, and a maximum five-minute queue wait. Historical measurements would be needed to justify those choices in a real service.
| Synthetic request | Estimated provider units | Work shape | Admission consequence |
|---|---|---|---|
| Ordinary export | 5 | One transformation | Fits a free slot and available units |
| Large legitimate export | 30 | One bounded large input | Allowed despite being larger than normal |
| Small request with three output formats | 36 | Three transformations at 12 units each | Budget the fan-out; request count alone misses it |
Suppose 40 units have already been settled today. The large export reserves 30, leaving 30 available: 100 − 40 − 30. A second account member requests the 36-unit fan-out. It is refused before provider admission even though a concurrency slot remains. A per-user budget would have missed this shared account cost.
The large export finishes at 24 actual units. Settlement atomically replaces its 30-unit reservation with 24 settled units. The account now has 64 settled and 36 available. The previously refused 36-unit request may now be admitted, subject to a free slot and the remaining controls. It is not admitted merely because the client retries: the current budget is recomputed.
Underestimation needs a rule too. In this design the worker obtains an additional reservation before crossing the reserved provider-unit ceiling, or stops before that call. Settling an unexpectedly large bill after the fact is accounting, not a hard spending bound. Whether the provider exposes a measurable unit before work starts is a required integration check. Define the budget period and timezone too. A midnight reset must not discard reservations for work still running: carry the liability forward or keep it charged to its original period under an explicit accounting rule. Retries retain that identity instead of receiving a fresh allowance.
A canceled worker is still capable of spending
Now the 36-unit job is canceled. Its lease expires, but its old process has not confirmed termination. Releasing all 36 units immediately would let a replacement or another member spend the same allowance while the old worker continues.
Northstar's proposed budget releases only the proven unused remainder. First establish either that the old attempt has stopped or that an enforcement point governing every further paid call rejects its stale attempt identity. In either branch, settle usage already admitted or keep a conservative reservation for outstanding and in-flight charges until they can be reconciled. A spending fence prevents new admission; it does not erase work already accepted by the provider. A lease timestamp alone proves neither termination nor an effective fence. The job authorization guide treats the broader stale-worker problem; here the consequence is double spending of reserved capacity.
The completed budget card becomes:
| Decision | Concrete Northstar setting and failure behavior |
|---|---|
| Scope | Account-wide provider budget shared by members, keys and retries |
| Per job | Estimate all selected transformations; reserve before admitting paid work |
| Concurrency / queue | Two active, four waiting; reject excess and expire a waiting job after five minutes without launching it |
| Unavailable budget store | Do not admit new paid work; preserve existing reservation identities |
| Settlement | Replace reservation with authoritative actual units once; duplicate settlement has no extra effect |
| Cancellation | Establish stop or effective spending fence; in either case settle or conservatively reserve already admitted/in-flight usage, then release only the proven unused remainder |
| Revision trigger | Owner revisits estimates if legitimate jobs repeatedly need extensions or queue waits exceed the chosen objective |
These settings are a provisional contract, not proof of implementation. The review now knows exactly which transaction, provider usage record and worker fence to inspect. It can reject the broad allegation that the IP limiter is the only defense if those mechanisms exist on the deployed path, while retaining a narrower reservation-release defect if cancellation bypasses them.
An API may signal excess frequency with HTTP 429 Too Many Requests; RFC 6585 says the response may include Retry-After. That status code is a communication choice, not evidence that all downstream budgets are correct. A deferred or queued operation needs its own clear status and cancellation semantics. Avoid publishing exact internal thresholds in an external security report when that detail is unnecessary to explain the risk; give operators the concrete limit and evidence in the authorized review record.
Explain a rejected expensive request without promising capacity
Northstar's caller needs to know whether work was admitted, deferred, or rejected before admission. A retry hint is useful only when it reflects the actual policy; it should not imply that a cancelled or timed-out job consumed no budget. Provide a stable job or operation reference for admitted work so the client can check its status instead of creating another export after an ambiguous response.
For operators, distinguish legitimate requests repeatedly denied by an overly narrow estimate from attempts exceeding the agreed contract. The former may require tuning the workload model or offering a separately bounded larger export. Neither should be resolved by bypassing the shared account ledger.
The review's final question is whether every costly path uses the same admission decision, including alternate API keys, scheduled exports, retries, and optional output formats. One successful gateway limit says little about a worker that can create unreserved provider calls. The budget card should point to the exact enforcing component for each resource, with unknown provider usage or process termination retained as unsettled liability.
Start with the most expensive authenticated endpoint and fill one budget card this week. If its risk comes from repeated business actions rather than compute or provider cost, continue with the checkout and credit-flow guide. If its cost scales with returned pages, review pagination and authorization leaks as well.