Getting an endpoint that works

You are not writing a subgraph. You need a key, an endpoint, and a clear view of what can go wrong between your application and the data.

1 of 4 in the App builder path beginner 9 min

Checked against Graph Horizon (2025-12-11)

Last read 2026-08-30 Due again 2026-11-30

Every protocol claim below was read at these sources on 2026-08-30. Where they disagree with each other, the lesson says so.

Somebody else has published the subgraph. You want to read it from your application and not think about the protocol again.

That is a reasonable goal and mostly achievable. This lesson is about the parts that are not automatic.

The shape of it.

Get an API key from Subgraph Studio, find the subgraph you need in Graph Explorer, and query its gateway endpoint over GraphQL with your key attached.

That is genuinely the whole integration. The rest of this path is about the assumptions that integration quietly makes.

your backend gateway indexer GraphQL response

Choosing a subgraph you can depend on.

Anyone can publish a subgraph. Some are maintained, some were a weekend project in 2023 that still indexes. Before building on one:

  • Is it the one the protocol team actually uses? Many protocols publish an official subgraph and it is usually the right choice.
  • Is it being served? Check that indexers are allocated to it. A published subgraph with no allocation returns nothing useful.
  • Is it healthy? Check indexing status. A subgraph that failed at some block has stopped, and it will keep answering with data up to that block.
  • Is it maintained? Contract upgrades break subgraphs. An unmaintained one breaks eventually and stays broken.
  • Does it carry signal? Signal is other people’s money betting it will keep being queried, which is a reasonable second opinion.

The three failure modes.

Stale. The subgraph is behind the chain head, or stopped entirely. Data is correct and old.

Empty. No matching entities. Indistinguishable in the response from stale or broken, which is what makes it dangerous.

Slow. Your query went to an indexer having a difficult afternoon, or your query is expensive. Set timeouts.

None of these throws an error. All of them are handled by checking indexing status alongside the data, which is the single highest-value thing you can add to the integration.

The key.

Never in a client. An API key in a web or mobile bundle is extractable and spendable by anyone who looks.

Query through your own backend, keep the key in server configuration, and rate limit per user there. This is ordinary practice for a paid API and it gets skipped here because the per-query amounts feel small.

Check yourself

A subgraph stopped indexing three months ago. What happens to your queries?

Where should your API key live?

The procedure Official querying guide This site explains why. The official documentation carries the exact steps, flags and config, and it is maintained by the people who ship the code. The numbers Every parameter on one page With the date somebody last read the source, and a note wherever two official pages disagree.