Sign in (opens in a new tab) Talk to GraphOps Create account (opens in a new tab)
Menu

Subgraphs

Build dashboards, activity views, and application APIs from indexed GraphQL entities using an existing Subgraph or one you publish.

Interface
GraphQL
Best for
Applications built around indexed entities and GraphQL schemas.
Create account (opens in a new tab) Read the docs (opens in a new tab)
Subgraphs
Your app GraphQL GraphQL
GraphOps Index Index
Ethereum New blocks Blocks

RecentRegistrations

Recently registered ENS names

Loading response data

What you get

  • GraphQL access to hosted Subgraph deployments
  • Deployment CID and Graph Network Subgraph ID addressing
  • Endpoint Aliases for application URLs
  • Indexing progress and health metadata
  • Managed indexing with Current and Next versions

Choose Subgraphs when

  • You need entities and relationships defined by a Subgraph schema.
  • A Subgraph for your contracts already exists, or your team can publish one with Graph CLI.
  • You want an Endpoint Alias that keeps your application URL unchanged across deployment changes.

Use another service when

  • You need direct contract reads at an explicit block, or you submit transactions.

    RPC

  • You need block-by-block history in your own database. Subgraphs serve the current indexed view.

    Substreams

What you can build with Subgraphs

Subgraphs answer GraphQL queries from indexed entities. These patterns cover the reads most applications need and how to keep a production endpoint stable while the Subgraph changes.

  1. 01 GraphQL · where · orderBy

    Dashboards and activity feeds from entities

    Show the largest pools, recent swaps, open positions, or the latest registrations with one GraphQL request. The Subgraph schema defines entities, their relationships, and generated filters and ordering, so a view selects exactly the fields it renders.

    1. Choose an existing Subgraph on The Graph Network, or publish your own with Graph CLI.
    2. Read its schema for entity names, fields, filters, and ordering.
    3. Request only the fields your view renders, and include _meta on important reads.
    You own
    The Subgraph you select and the queries your views send.
    Plan for
    Query complexity, response size, and timeouts are limited for each organization. Prefer several bounded queries to one unbounded query.
    Query a Subgraph(opens in a new tab)
    One query returns related pool and token entities from the index, shaped for the view. The pairs shown are illustrative.

  2. 02 first · id_gt · orderBy

    Pagination through large entity sets

    Export every pool, holder, or vote for a report or a sync job. Order by a stable field and filter past the last id you received, so each page is bounded and a worker can resume after a retry.

    1. Order by a stable field such as id.
    2. Request a bounded page with first and where: { id_gt: $lastId }.
    3. Store the last id after each page, and stop when a page returns fewer rows than requested.
    You own
    Page size, the stored position, and retries.
    Plan for
    Later pages can read newer data than earlier ones. Pin every page to one block with the block argument, or log _meta.block.number with each page.
    Paginate results(opens in a new tab)
    Each page starts after the last id of the one before it. A short page ends the scan.

  3. 03 _meta · block · hasIndexingErrors

    Indexing progress with every answer

    Answers come from the latest indexed block, which can trail the chain head. Include _meta to see the block and deployment behind a response and whether indexing errors are present. Show freshness to users, alert on lag, and treat recent results as revisable until your network's finality.

    1. Add _meta { deployment block { number hash } hasIndexingErrors } to health checks and important queries.
    2. Track block.number over time and compare it with a reliable head source for the same network.
    3. Alert when hasIndexingErrors is true, and include the block hash in support requests.
    You own
    Freshness thresholds and how your product presents lag and reorg corrections.
    Plan for
    _meta reports indexing progress, not the chain head. Compare it with a head source for the same network to measure lag.
    Monitor sync health(opens in a new tab)
    The index has reached block N while the chain head is at N+2. The answer arrives with _meta reporting N.

  4. 04 Managed Subgraph · Endpoint Alias

    Upgrades behind a stable Endpoint Alias

    With a Managed Subgraph, GraphOps keeps your deployment indexed. Prepare a Next version while Current serves queries, then promote it when it meets the readiness checks. An Endpoint Alias that targets the Managed Subgraph follows the promoted version, so clients keep the same URL. To index and promote the owner's published versions automatically, follow a Graph Network Subgraph ID instead.

    1. Add a Managed Subgraph by Deployment CID and link an Endpoint Alias to it.
    2. Choose Start upgrade with the next Deployment CID, review the schema comparison, and test the Next version.
    3. Choose Promote version when Next is healthy and meets the readiness checks.
    You own
    Release decisions, client compatibility, and your recovery plan.
    Plan for
    Managed indexing accrues charges even when no queries are sent, and both versions can accrue charges during an upgrade. Returning to a previous deployment takes another upgrade, not an instant rollback.
    Keep a Subgraph indexed and manage upgrades(opens in a new tab)
    The Endpoint Alias serves Current while Next indexes. Promotion moves the alias to the new version without changing your application URL.

What GraphOps runs and what you own

GraphOps serves your GraphQL queries and, for Managed Subgraphs, runs the indexing. Your team chooses the schema, the queries, and when a new version reaches users.

Your application owns

  • The Subgraph and schema your product depends on
  • Queries, page sizes, and retries
  • Upgrade decisions and client compatibility
  • Handling indexing lag and reorg corrections

GraphOps runs

  • GraphQL endpoints for Subgraphs available through The Graph Network
  • Indexing for your Managed Subgraphs, with status, sync lag, and a cost estimate in the platform
  • Endpoint Alias resolution and promotion readiness checks

Networks

Queries reach any Subgraph on The Graph Network, and the deployment selects its network. Managed indexing runs your deployments on the networks below, from the live catalog.

See supported networks

Limits to plan for

  • Query rate, timeout, response size, and complexity limits are shared across your organization.
  • A Managed Subgraph deployment must use one supported network across all data sources and templates.
  • Run introspection in development or CI, not on every request.
Usage and limits(opens in a new tab)

Supported networks

Queries reach any Subgraph on The Graph Network, and the deployment selects its network. Managed indexing runs your deployments on the networks below, from the live catalog.

Loading the live network catalog

Plan your integration

Go from a new organization to a first response, then prepare for production traffic.

  1. 01

    Create an organization and add credits

    Choose your monthly credits or buy a top-up. Queries consume credits per request. Managed Subgraphs need a monthly plan, and their indexing accrues hourly charges while it runs.

  2. 02

    Create an API key for Subgraphs

    Send it as a bearer token in the Authorization header, or in the endpoint path for clients that cannot set headers.

  3. 03

    Choose how to address the Subgraph

    Pin a Deployment CID, follow a Graph Network Subgraph ID, or query an Endpoint Alias your organization controls. An Endpoint Alias that follows a Graph Network Subgraph ID can keep serving the previous version until indexers serve a new one.

  4. 04

    Query the deployment

    Run a GraphQL query that includes _meta to see the entities and the block that served them.

  5. 05

    Prepare for production

    Bound page sizes, include _meta in health checks, and treat GraphQL errors as failures even when the HTTP status is 200. Point production clients at an Endpoint Alias.

Endpoints

Deployment CIDStays on one deployment and schema
https://subgraphs.graphops.xyz/v1/deploymentCID/<DEPLOYMENT_CID>
Graph Network Subgraph IDFollows the owner's published versions
https://subgraphs.graphops.xyz/v1/subgraphId/<SUBGRAPH_ID>
Endpoint AliasFollows the target your organization chooses
https://subgraphs.graphops.xyz/v1/alias/<ALIAS>

Query any Subgraph available through The Graph Network by Deployment CID or Graph Network Subgraph ID. Managed indexing has its own list of supported networks.

Prerequisites

  1. Set GRAPHOPS_API_KEY to your GraphOps API key.

  2. Replace <UNISWAP_DEPLOYMENT_CID> with the Deployment CID of a Uniswap-style Subgraph.

CLI · curl

Example project
curl --fail-with-body --silent --show-error "https://subgraphs.graphops.xyz/v1/deploymentCID/<UNISWAP_DEPLOYMENT_CID>" \
  -H "Authorization: Bearer ${GRAPHOPS_API_KEY}" \
  -H "Content-Type: application/json" \
  --data '{
    "query": "query TopPools { pools(first: 5, orderBy: totalValueLockedUSD, orderDirection: desc) { id token0 { symbol } token1 { symbol } totalValueLockedUSD } _meta { block { number hash } hasIndexingErrors } }"
  }'
Query your first Subgraph(opens in a new tab)

Query your first Subgraph.

Choose a deployment and schema, add credits, and follow the GraphQL quickstart.

Create account (opens in a new tab) Read Subgraphs docs (opens in a new tab)