Launch with credentials you can replace, data you can trust, and failures you can diagnose and recover from. Work through this checklist with your team after your first successful request, then follow your service's usage and troubleshooting pages for protocol-specific decisions.
Credentials and access
- Create a separate API key for each environment and workload, with a label that names it.
- Store keys in a secret manager or server-side runtime configuration.
- Keep keys out of logs, analytics events, support messages, and source control.
- Ship a key to the browser only as a browser key: every service on it limited to your production site's origins and to what it queries, separate from the keys your servers use.
- Confirm each production key belongs to the intended organization and includes only the services its workload uses, limited to the networks or Subgraphs it queries.
- Decide who can rotate and revoke production keys, and test a rotation before launch.
See API keys and the authentication page for your service.
Billing, credits, and limits
- Size your monthly credits to cover launch traffic.
- Turn on automatic top-ups with a spending limit
you are comfortable with, so a traffic spike adds credits instead of pausing your services. At zero
or below, requests pause and return
403with the codecredits_exhausted. - Set low-credit alerts so the right people hear before the balance runs out.
- Check your organization limits for API keys and Managed Subgraphs, and ask support for an increase before you need it.
- Read your service's usage page before choosing concurrency, batch size, or backfill strategy.
- Treat access (
403) and limit responses as configuration or billing problems; do not retry them indefinitely.
Data correctness
Decide how fresh and how stable each result must be, then use the service's tool for it.
| Service | Correctness decision |
|---|---|
| RPC | Anchor multi-request workflows to an explicit block number, hash, safe, or finalized reference. |
| Subgraphs | Inspect _meta when indexing freshness or indexing errors affect the result. |
| Substreams | Persist cursors only after committing output, and handle undo signals for reversible data. |
Timeouts and retries
- Set explicit connection and request timeouts.
- Retry transient failures with bounded exponential backoff and jitter.
- Respect server retry guidance when a response supplies it.
- Give each workflow a retry budget so a downstream failure cannot create unbounded traffic. Successful retries can count as additional usage.
Observability
Record enough context to diagnose a failed request without recording secrets. One structured entry per failed attempt is enough to answer most support questions:
Reference example
{ "time": "2026-10-21T14:03:12Z",UTC timestamp "service": "rpc",GraphOps service "organization": "acme-production",Organization name or ID "apiKeyLabel": "production-indexer",Key label, never the key "endpoint": "/v1/evm/1",Network or endpoint path "status": 429,HTTP or gRPC status "error": "Too Many Requests",Safe error detail "requestId": "<REQUEST_ID>",When the response supplies one "attempt": 2Retries used from the budget}For Subgraphs, record the Endpoint Alias or Deployment CID and
_meta.block.number. For Substreams, record the package, module, and last committed cursor or
block when it is safe to share.
Recovery
- Define what each client does after a disconnect or partial workflow failure.
- Make writes and materialization steps idempotent wherever a retry can repeat work.
- Test the troubleshooting path for each service you use.
- Decide who contacts GraphOps support(opens in a new tab) and which sanitized details they provide.
Next steps
Last updated