GraphOps Subgraphs

Build dashboards, activity views, and application APIs from indexed blockchain entities. GraphOps Subgraphs serves the open Subgraph standard over GraphQL, so you can query an existing deployment on The Graph Network or a Subgraph you publish yourself, and let GraphOps keep your own Subgraph indexed.

Your appGraphQL

SubgraphsIndex

ChainNew blocks

New blocks are indexed as they arrive. Your app's GraphQL queries are answered from that index.

Create API key Run the quickstart Browse reference

Where to start

Query an existing Subgraph

Create an API key, choose a Deployment CID, and run your first GraphQL query.

Choose your setup

Decide what happens to your queries when a new version is released.

Keep your Subgraph indexed

Let GraphOps run indexing and promote new versions when they are ready.

Your application sends one GraphQL query. GraphOps answers from the indexed entities and reports the block behind the answer in _meta. The pairs shown are illustrative.

Each Subgraph defines its own schema of entities and relationships. GraphOps answers your query from the latest indexed block and reports that block in _meta. Everything after the response belongs to your application: which fields you request, how you page through results, and how you present freshness to users.

What you can build

Views that read entities, not node calls. Show the largest pools, recent swaps, or open positions with one query. See Query a Subgraph.
Exports and sync jobs over large collections. Walk every entity in bounded pages that a worker can resume. See Paginate results.
Freshness checks with every answer. Detect indexing lag and errors before stale data reaches users. See Monitor sync health.
Releases behind a stable URL. Test each new version of your Subgraph, then move your application to it without changing its endpoint. See Develop and release a Subgraph.

Choose Subgraphs when

Use Subgraphs when your application needs entities and their relationships, such as pools, positions, or votes, and an existing GraphQL schema fits or you can build one with Graph CLI.

Use another GraphOps service when your job is different:

Need	Use
Direct contract reads at an explicit block, or transaction submission	RPC
Block-by-block history or an ordered stream into your own storage	Substreams

Choose how you address a Subgraph

Every query goes to one of three endpoint shapes. The choice decides who moves your application to a new version:

Identifier	Endpoint shape	Who changes the version
Deployment CID	`/v1/deploymentCID/<DEPLOYMENT_CID>`	No one. It always serves the same deployment.
Graph Network Subgraph ID	`/v1/subgraphId/<SUBGRAPH_ID>`	The Subgraph owner, by publishing on The Graph Network, before the new version is indexed.
Endpoint Alias	`/v1/alias/<ALIAS>`	Your organization, through the Endpoint Alias target.

An Endpoint Alias can also target a Managed Subgraph, which moves only after a new version is indexed and promoted. Choose your Subgraph setup recommends a setup from a few questions, and Identifiers and Endpoint Aliases explains what each one does during an upgrade. Query access covers Subgraphs available through The Graph Network, on every network it serves; managed indexing runs on a smaller set. Supported networks lists both.

Plan for production

Before you rely on query results:

Include _meta on important reads and design for indexing lag. Recent data can be corrected by a chain reorganization.
Treat a GraphQL errors array as a failure even when the HTTP status is 200.
Use an Endpoint Alias for production clients so a release does not require an application change. Target a Managed Subgraph when new versions should reach clients only once indexed.

Queries and managed indexing use the rates on Usage and limits.