A monthly request estimate is more useful when it starts with application actions rather than a guess about “active users.” Two apps with the same audience can make very different numbers of calls.
List the actions that reach the API: submitted searches, autocomplete requests, show-page loads, next pages, listener updates, and scheduled refreshes. Use only the operations your product actually performs.
Build a small model
For each action, estimate frequency and calls per action. Multiply those values, then add the categories. Keep assumptions visible. A search screen that sends one request per submitted query differs from a screen that sends suggestions after every pause.
Account for cache reuse and retries separately. Avoid subtracting an optimistic cache saving from every category before you have measured it. Include scheduled jobs even when no person is using the app at that moment.
A useful first estimate has a normal case and a busy case. The busy case can include a release-day traffic increase or a batch of new subscriptions. It should remain a plausible scenario rather than an unexplained large safety multiplier.
Compare the model with reality
In a test environment, count calls for a few complete user journeys. Then measure production categories with non-secret operational counters. Compare the result with your estimate and explain any gap.
Use the current pricing page for plan limits and billing terms. Do not copy a price into a long-lived architecture document and assume it will stay current.
The budget is a design tool as well as a purchasing tool. It can show where combining duplicate metadata requests or reducing unnecessary autocomplete calls improves both cost and the listener's experience.