Estimate what your RPC workload will cost and keep it within your organization's shared limits. RPC calls and WebSocket subscription events draw credits at the rates for their method class. Rate and concurrency limits apply to your whole organization.
Current credit rates
Use the method rates below to estimate request costs. Track actual consumption in Platform Usage.
Current rates as of Nov 14, 2026, 12:03 AM UTC.
| Usage component | Applies to | Rate |
|---|---|---|
| RPC calls | Default | 20 credits per RPC call |
| RPC calls | RPC method cost class: Standard | 20 credits per RPC call |
| RPC calls | RPC method cost class: Compute-heavy | 30 credits per RPC call |
| RPC calls | RPC method cost class: Log scans | 40 credits per RPC call |
| RPC calls | RPC method cost class: State proofs | 40 credits per RPC call |
| RPC calls | RPC method cost class: Trace and debug | 60 credits per RPC call |
| Subscription events | Default | 20 credits per subscription event |
| Subscription events | Subscription type: newHeads | 20 credits per subscription event |
| Subscription events | Subscription type: logs | 20 credits per subscription event |
| Subscription events | Subscription type: newPendingTransactions | 20 credits per subscription event |
| Subscription events | Subscription type: syncing | 20 credits per subscription event |
| Response bytes | Default | 0 credits per GiB |
| Response bytes | RPC method cost class: Log scans | 1,500,000 credits per GiB |
RPC method cost class
| Class | Methods |
|---|---|
| Compute-heavy | eth_call, eth_createAccessList, eth_estimateGas |
| Log scans | eth_getLogs |
| State proofs | eth_getProof |
| Trace and debug | debug_…, trace_… |
| Standard | All methods not matched by another class |
Credits follow the method's cost class, not the block's age, so an archive read uses the same credits as a current-state call to the same method. Check Supported networks for archive coverage on your network.
Organization limits
These limits apply to your whole organization, not to each API key, and they do not change with your plan size. Contact support for the values that apply to your workload or to request an increase.
| Limit | Applies to | Guidance |
|---|---|---|
| Request rate | HTTPS and WebSocket RPC calls | Spread traffic across time and use backoff after 429. |
| Concurrent requests | In-flight requests for the organization | Bound worker pools and queue background jobs. |
| Batch size | Number of JSON-RPC calls in one HTTP batch | Keep batches small enough to retry individual failures. |
| Response size | Large logs, blocks, receipts, and archive reads | Use narrower ranges or paginated application workflows. |
| Request timeout | Long state reads and log scans | Split large archive jobs by block range. |
| WebSocket connections | Live subscriptions | Reuse connections and unsubscribe unused streams. |
| WebSocket subscriptions | Active subscriptions per organization | Prefer one filtered subscription over many overlapping ones. |
Rate-limit and request headers
Treat optional headers as informational
Do not rely on rate-limit or request-tracing headers to enforce production limits. Handle 429
responses, use bounded concurrency, apply backoff with jitter, and monitor usage in the platform UI.
Responses may include headers such as:
HTTP
X-GraphOps-RateLimit-Limit: <LIMIT>
X-GraphOps-RateLimit-Remaining: <REMAINING>
X-GraphOps-RateLimit-Reset: <unix-seconds>
X-GraphOps-Request-Id: <request-id>
These headers are informational; availability can vary by endpoint.
Control your usage
Most limit errors come from a few workload shapes. Keep each one bounded:
| Workload | Keep it within limits | Guide |
|---|---|---|
| Current-state reads | Retry 429, 502, 503, and 504 with exponential backoff and jitter, and cap total retry time. | Retries and reorgs |
| Log scans and archive reads | Split work into block ranges and reduce the range before retrying. | Backfill historical events |
| Batch requests | Keep batches small, match responses by id, and retry only failed retryable items. | API integration |
| Transaction submission | Retry the same signed transaction; never change it and resend blindly. | Send a raw transaction |
| WebSocket streams | Reuse connections, unsubscribe unused streams, and backfill gaps after a reconnect. | WebSocket subscriptions |
Production checklist
- Store API keys outside source code. See Authentication.
- Bound request concurrency per organization.
- Add exponential backoff with jitter for retryable errors.
- Use explicit block references for multi-call workflows.
- Split broad
eth_getLogsand archive reads into block ranges. - Track credit usage in the platform UI.
- Use route-token authentication for WebSocket clients that cannot send custom headers.
- Contact GraphOps support(opens in a new tab) when limits need to be raised.
Next steps
Last updated