What counts
One billable REST data request or civic MCP tool call counts once when it is admitted, including work that later fails. A request refused before admission, such as a failed authentication or a rejected limit, is not counted.
Missing-data report operations are not billable data calls and draw zero allowance: submitting or checking a report never counts against a plan, and a report still needs the account's current paid access. The separate abuse limit below still applies to those keys.
All keys on the account share one quota, and billable REST and MCP requests draw on the same admitted requests. A bounded REST batch is one admitted request, and the batch endpoint accepts at most 100 record IDs. A top-level MCP JSON-RPC batch array is not supported and is rejected.
Paid subscription REST response bodies are capped at 1,000,000 bytes. This measures the complete serialized response body, including its envelope. The API reference lists a stored account default of 5,000,000 bytes; paid plans use their own lower limit. Page row limits are separate from response byte limits. An MCP request body is capped at 64 KiB, and an MCP tool result is capped at 16 KiB.
Recognized subscription keys on an account are also subject to an abuse limit of 1,000 requests per minute and 100 per second, including requests that are refused. Usable keys and revoked or expired keys are counted separately, so a compromised key you rotate or revoke does not use up your new key's capacity. This is separate from paid usage. If the limit is reached, retry after the time in Retry-After. If the limit cannot be checked, requests return 503.
Monthly limits by plan
Each plan has its own hard limits for one paid month. The allowance does not carry over to the next period, and it is not pooled across plans.
The limits apply while the account has paid data access. Without a current paid plan period the plan allowance does not apply, and those keys do not authenticate on the civic read and export routes until paid access returns. Report calls need current paid access of their own, and a report never draws on the plan allowance.
Every valid key on the account draws on the same allowance. A valid key is one that is not revoked and has not expired, and each plan limits how many valid keys an account can hold.
- Builder: 10,000 admitted requests and 1 decimal GB of response bytes per paid month. 60 requests per minute, a burst of 5 per second, 2 concurrent requests, and up to 100 rows per response.
- Pro: 50,000 admitted requests and 5 decimal GB of response bytes per paid month. 120 requests per minute, a burst of 10 per second, 4 concurrent requests, and up to 250 rows per response.
- Ultra: 200,000 admitted requests and 20 decimal GB of response bytes per paid month. 300 requests per minute, a burst of 20 per second, 8 concurrent requests, and up to 500 rows per response.
Feed subscription caps
A feed subscription is a separate count from keys and requests. A feed subscription is active while the feed is unrevoked and its bound key is unrevoked and unexpired, and the account holds its plan's number of active feed subscriptions across every key.
Feed subscriptions need a current paid period on Pro or Ultra. A plan that carries none refuses every feed-subscription operation, and an account that moves between the two eligible plans keeps its existing feeds and their polls while new creation is refused above the new plan's count.
- Pro: 10 active feed subscriptions per account.
- Ultra: 100 active feed subscriptions per account.
When a limit is reached
- Traffic over a plan limit returns 429 with a quota-specific error code and Retry-After. Wait for the number of seconds in Retry-After before you retry.
- There is no automatic overage charge, and no plan exceeds its limit silently.
- The allowance resets only in a new paid period. Ending the subscription does not reset it, and a refund or dispute revokes access without resetting the used allowance, so the account needs a new paid period.
- A plan cannot be changed mid-period. Plan changes are not available.
Recorded usage
The account shows the selected plan and the recorded usage for the selected billing period: requests used and response bytes used. Those figures come from the trusted billing record, so they report what was counted rather than what a later call may use.
When the usage record cannot be read, the account says the usage details are unavailable instead of showing zero.