Query a public Subgraph through GraphOps without changing its schema or your GraphQL queries. The one decision you make is who controls the version you query: pin a Deployment CID to stay on one version, or use a Graph Network Subgraph ID to follow the owner's upgrades.
Prerequisites
- A GraphOps Platform account.
- An organization with access to Subgraphs.
- A public Deployment CID or Graph Network Subgraph ID.
- An API key that includes Subgraphs.
Connect
Choose the identifier
Choose one identifier:
| Identifier | Use it when |
|---|---|
| Deployment CID | You want one exact deployment and schema. |
| Graph Network Subgraph ID | You want the endpoint to follow upgrades on The Graph Network, and can accept failed or incomplete queries while each new version is indexed. |
For a Subgraph you control, the standard Graph CLI deployment output includes the Deployment CID after publishing. For a public Subgraph, use the identifier published by the Subgraph owner, or find it in Discover Subgraphs.
Choose the query endpoint
Use the route that matches your identifier:
Reference
https://subgraphs.graphops.xyz/v1/deploymentCID/<DEPLOYMENT_CID>
https://subgraphs.graphops.xyz/v1/subgraphId/<SUBGRAPH_ID>
Authenticate with a query key that includes Subgraphs, as described in Authentication. If you want GraphOps to run indexing for your deployment, follow Managed Subgraphs. Use a Deployment CID to manage releases manually, or a Graph Network Subgraph ID to index and promote future published versions automatically.
Add a stable name if you need one
Create an Endpoint Alias when application code should use a stable organization-owned name:
Reference
https://subgraphs.graphops.xyz/v1/alias/<ALIAS>
An Endpoint Alias with a Deployment CID target stays on that CID; a Managed Subgraph target follows its serving Current version; a Graph Network Subgraph ID target follows the latest validated publication for that ID. Choose the Endpoint Alias target based on who should control releases and whether endpoint changes should wait for Managed Subgraph indexing readiness. Choose your Subgraph setup recommends one for production.
Verify query access
Send this GraphQL query to your chosen endpoint using your API key:
GraphQL
query ImportedSubgraphStatus {
_meta {
deployment
block {
number
hash
}
hasIndexingErrors
}
}
Output
{ "data": { "_meta": { "deployment": "QmTZ8ejXJxRo7vDBS4uwqBeGoxLSWbhaA7oXa1RvxunLy7",The deployment your endpoint resolved to "block": { "number": 26285621,Highest indexed block served "hash": "0x40c3154aaa484a99057c58a6c72c27171ed861d260179db387850027655d0881" }, "hasIndexingErrors": falseShould be false before you build on it } }}If _meta.deployment is not the deployment you expected, check the identifier and endpoint shape.
A Graph Network Subgraph ID endpoint moves when the owner publishes a new version, so record the
deployment you tested against.
Before production
- Confirm schema compatibility before you point an Endpoint Alias used by production clients at a new deployment.
- Don't point production clients at the
subgraphIdendpoint if they need data through upgrades. It moves to each new version before indexers serve it; an Endpoint Alias that targets a Managed Subgraph waits until the new version is ready. - Use Endpoint Aliases when your organization needs controlled upgrades, rollbacks, or environment-specific endpoints.
- A Deployment CID keeps the code and schema version fixed; indexed data continues to change.
Next steps
Last updated