This lesson's interactive features are locked, please to keep using them

Usage Quotas

Rate limits cap short-window activity, like "10 requests per minute," while quotas cap sustained usage, like "1,000 exports per month." The first protects your server from being overwhelmed right now; the second limits cost and abuse over time.

Modern web apps often trigger expensive work behind the scenes: sending emails, generating PDFs, calling third-party APIs, running AI inference, or processing payments. Quotas simply put a ceiling on that cost.

Good candidates include email sends, SMS messages, AI completions, image generation, and report exports. They're either expensive per unit or abusable at volume... but usually both.

Checking the quota and incrementing usage must be atomic. If you read first and write later, concurrent requests can all spend the same last remaining unit.

Assignment

The warehouse integration can use its API key without a long-term ceiling.

Enforce the prebuilt daily quota.

In internal/api/handler.go, update WarehouseOrders to call the provided ConsumeQuota method only after the API key and its orders:read scope are validated.
Handle quota results with the provided SetQuotaHeaders and RespondWithQuotaExhausted helpers:
- Set the limit, remaining, and UTC-day reset headers.
- Return the quota-exhausted response and stop when the request isn't allowed.
Include the result of ToQuotaResponse under quota in each successful warehouse response.
Handle quota-consumption errors with the route's existing internal-error response.
Start the app.

With Bearly Secure still running, run and submit the CLI tests from the project root.