# Connect an existing Subgraph

Source: https://docs.graphops.xyz/subgraphs/guides/import-existing-subgraph

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-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](./discover-public-subgraphs).

### Choose the query endpoint \[#choose-the-query-endpoint]

Use the route that matches your identifier:

```text
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](../authentication).
If you want GraphOps to run indexing for your deployment, follow
[Managed Subgraphs](../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 \[#add-a-stable-name-if-you-need-one]

Create an Endpoint Alias when application code should use a stable organization-owned name:

```text
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](./manage-aliases) based on
who should control releases and whether endpoint changes should wait for Managed Subgraph indexing
readiness. [Choose your Subgraph setup](../choose-a-setup) recommends one for production.

### Verify query access \[#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

```json
{
  "data": {
    "_meta": {
      "deployment": "QmTZ8ejXJxRo7vDBS4uwqBeGoxLSWbhaA7oXa1RvxunLy7",
      "block": {
        "number": 26285621,
        "hash": "0x40c3154aaa484a99057c58a6c72c27171ed861d260179db387850027655d0881"
      },
      "hasIndexingErrors": false
    }
  }
}
```

The deployment your endpoint resolved to

Highest indexed block served

Should 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 `subgraphId` endpoint 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

* [Query a Subgraph](./query-a-subgraph): Read entities from the endpoint and handle GraphQL errors.
* [Manage Endpoint Aliases](./manage-aliases): Give production clients a stable URL you control.
* [Identifiers and Endpoint Aliases](../concepts/identifiers-and-aliases): Compare who controls each identifier's version.