Docs
⌘ K

4 minutes

Consumer-Side

The consumer side of running a Subgraph Gateway includes everything facing the developers and applications that query it. To those users, an Operator’s Gateway is the product: a single endpoint, an API key or an x402 payment system, and fast GraphQL responses drawn from The Graph Network. This section covers how an Operator presents network access to consumers, how an Operator prices it, how they query and authenticate, how an Operator curates data for them, how they publish Subgraphs, and how an Operator supports them.

Where Gateways Interface with the Subgraph Network

The Graph Network is a decentralized set of Indexers who sync and serve data from Subgraphs. A data consumer could query those Indexers directly, but doing so means discovering which Indexers serve a given Subgraph, judging their quality, handling failover, and settling per-query payment on-chain. Almost no consumer wants this.

Gateways abstract much of that complexity. They sit between most consumers and the network of Indexers: consumers send a query to one endpoint, and then Gateways discover the Indexers that can serve it, route requests to the best candidates, absorb individual Indexer failures, and settle payments on the consumer’s behalf. From the consumer’s perspective, the decentralized network looks like a single reliable API.

For a service provider, this is where the commercial relationship lives. An Operator owns the endpoint, the authentication, the pricing, and the support experience, while The Graph Network provides the indexed data underneath. See the Overview for how this enables vertical integration.

Functions of a Gateway for Consumers

A Gateway performs three core functions on behalf of the consumers who use it, with a fourth that is optional.

Authentication and API Keys

A Gateway identifies who is making each request and enforces what they are allowed to do. It supports two methods: API keys (Authorization: Bearer <API_KEY>) for humans and applications, and x402 pay-per-query in USDC for autonomous agents with no account.

API keys are the primary way human developers consume a Gateway. A Gateway Operator issues keys, attaches restrictions and rate limits, tracks usage per key for billing, and revokes or caps keys as needed. Keys can be scoped to specific Subgraphs, domains, and rate limits, and they are also the unit that curation and collections attach to. Learn more in the Serving Queries section.

Routing

The Gateway turns one consumer query into a routed request across the network. It resolves Subgraph IDs or Deployment IDs, discovers the Indexers with active allocations, selects up to three by quality and cost, and returns the first response that passes its filters. The consumer never chooses an Indexer. The Gateway does it for them, continuously routing around slow or failing ones. The selection logic is covered in Indexer Selection.

Payments

A Gateway pays Indexers for the queries it serves, so the consumer does not have to transact on-chain per query. Behind a simple usage-based bill or a pay-per-query charge, the Gateway signs Graph Tally receipts and settles them in batches. This is what lets an Operator offer consumers familiar pricing (a monthly bill, a card on file, or per-query USDC) on top of a micropayment network. See Pricing & Payments.

Optional: Staging Environments

Some operators offer consumers a staging path: an environment for testing new Subgraph versions before moving production traffic to them, often backed by a dedicated indexing environment for pre-indexing and debugging. This is optional and depends on a Gateway’s Indexing Approach.

What Is In This Section