Every deployed subgraph exposes a GraphQL endpoint. You can query it from any HTTP client — no special SDK is required.
Endpoint URL#
Decentralised network queries go through the Gateway:
https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>- API_KEY — create one at Subgraph Studio.
- SUBGRAPH_ID — the deployment ID shown on Graph Explorer.
Basic Query#
Fetch recent swaps from the Uniswap V3 subgraph:
|
|
TypeScript Client#
The lightweight graphql-request library is a good default:
|
|
For heavier use, consider urql or Apollo Client which add caching and React integration.
Filtering#
The auto-generated where argument supports equality, comparison, and containment filters:
|
|
Suffix conventions: _gt, _gte, _lt, _lte, _in, _not_in, _contains, _starts_with.
Pagination#
Subgraphs cap results at 1 000 entities per query. For larger datasets, paginate using first + skip or, for better performance, cursor-based pagination with id_gt:
|
|
Cursor-based pagination (id_gt) is faster than skip for deep pages.
Time-Travel Queries#
Query the subgraph state at a specific block with the block argument:
|
|
This is useful for building historical snapshots or comparing state across blocks.
Full-Text Search#
If the subgraph schema defines a @fulltext directive, you can search across text fields:
|
|
Full-text search must be declared in schema.graphql at build time — it cannot be added at query time.
Performance Tips#
- Request only the fields you need — over-fetching nested relations is the most common cause of slow queries.
- Cache on your backend — the decentralised gateway charges per query. A short TTL (30–60 s) dramatically reduces costs for dashboards.
- Batch related queries into a single GraphQL request to reduce round trips.
- Avoid deep
skippagination — switch toid_gtcursors for datasets beyond a few thousand entities. - Use
_metato check indexing status before trusting results:
|
|
If hasIndexingErrors is true, the data may be incomplete.