What is not billed: error codes and billing rules

BlockVectra meters requests in Compute Units (CU). Calls are billed only after a response is obtained; units are not deducted when a request arrives. This guide summarizes the billing determination rules across HTTP status codes, JSON-RPC calls, and the Data API, along with recommended actions for developers.

HTTP Status Codes and Billing RulesCopy Anchor Link

The billing determination and handling rules for HTTP-level responses are as follows:

Note: When accessed through Cloudflare, Cloudflare may return 52x or 1015 error pages; these are not generated by the service.

JSON-RPC Error Codes and Billing RulesCopy Anchor Link

The same error code can originate from the platform or the node, and billing differs:

• Errors generated by the platform itself: never billed;
• Errors returned by the node: passed through as-is and billed at the method weight, with only the node error codes listed below as exceptions.

Rule DetailsCopy Anchor Link

• Node errors not billed: The node's -32002 (batch timeout), -32003 (batch response too large), and -32600 (batch rejected as a whole) indicate that the node abandoned the call early and are not billed; notifications in the same batch are also not billed. 4444 indicates the requested block was pruned by the node (the node retains roughly 7 days of history), is not billed, and does not affect other calls in the batch. -32000 (only for historical state ... is not available, and Erigon's old data not available due to pruning...) indicates the request falls outside the node's state history window (roughly 128 blocks), is not billed, and does not affect other calls in the batch. Erigon has a window of about 36 days, is not billed, and does not affect other calls in the batch.
• Node errors billed: Other errors returned by the node count as work done by the node and are billed at the method weight, such as execution reverted (-32000 or 3 with data), the node's own -32602 invalid argument, or -32601 returned for an eth_* method that passed platform admission but is not implemented by the node.
• Balance admission and sync: -32020 indicates insufficient account balance and requires a top-up; -32021 indicates billing data is temporarily unavailable and the request is temporarily rejected—this is not a balance issue, no need to top up, simply wait the seconds specified in Retry-After and retry. A newly created key returns -32021 before the system reads billing data for its account (usually within a few seconds), not -32020; after reading, accounts with balance are accepted as normal, while accounts truly depleted or deleted receive -32020 (402).
• Upstream failures: A -32603 generated by the platform due to upstream communication failure or malformed response (upstream unavailable, no response from upstream, malformed upstream response) carries data.reason: upstream_unavailable; internal gateway error is generated only in extremely rare cases of internal task panic or cancellation, does not represent upstream failure, and carries no data.reason.
• Notification billing: Notifications (204) are billed as normal. Notifications are billed when the node processes the batch successfully: upstream HTTP 2xx; when the batch has calls with an id, at least one received a normal response and there are no -32002/-32003/-32600 elements; requests containing only notifications are billed if the upstream returns 2xx with an empty body.

JSON-RPC Error Codes TableCopy Anchor Link

Data API Billing RulesCopy Anchor Link

The Data API wraps read-only chain data into REST endpoints. Its billing and error handling follow these rules:

Rule DetailsCopy Anchor Link

• "A Data API request is billed only when it succeeds."
• "Requests are metered and billed in Compute Units (CU); only 2xx successful responses are billed."
• "Chain-specific operations that are unavailable (e.g. unsupported chain or outside trace coverage) return HTTP 422 and are not billed."
• "Requests outside our data coverage are not billed but may count toward rate limits."
• "There are two exceptions for 404 errors: an unknown or not-public chain returns HTTP 404 with error.code not_found (decided before the key check, not billed, and not rate-limited; chain names must be exact lowercase slugs), while a missing, unknown, or disabled API key gets HTTP 404 with an empty body (identical to JSON-RPC). Requests exceeding rate limits return HTTP 429 (error.code rate_limited with data.reason key_rate_limit), and exhausted balances return HTTP 402 (error.code insufficient_balance); neither is billed."

Data API Status Codes TableCopy Anchor Link

Testing note: These rules were confirmed on 2026-09-30 with a new free-plan account on the production environment: rejected methods (-32601), a syncing node (-32010), and the Data API's 409 finality_exceeded and 422 no_coverage did not add to usage, while successful calls were metered at the weights published by GET /v1/plans. This is a single observation, not a guarantee.

Pricing and UpgradesCopy Anchor Link

The specific cost for all billed calls is determined by published CU weights:

• To inspect weights for all methods and operations, see the method weight table and the JSON-RPC CU Metering Rules.
• For plan pricing and settlement details, see the Pricing page.
• Upgrading to a paid plan: making a paid top-up removes the Free Plan's per-second call limit; each key remains subject to CU rate and burst limits.