---
title: Subgraph Gateway
sidebarTitle: Overview
---

A Subgraph Gateway is the entry point between Data Consumers and the Indexers who serve their data on The Graph Network. This documentation is written for teams who want to operate a Gateway: it covers what a Gateway does, how it fits into The Graph, and the consumer-side and supply-side responsibilities that come with running one.

## Who Runs Subgraph Gateways

| Operator type              | Benefits of Subgraph Gateway                                                           |
| -------------------------- | -------------------------------------------------------------------------------------- |
| Data and API providers     | Resell access to 15,000+ Subgraphs under own brand and billing                         |
| Analytics platforms        | Query protocol data across many chains without maintaining own indexing infrastructure |
| Wallets and portfolio apps | Position and activity data without protocol-specific indexing                          |
| AI data services           | x402-native, pay-per-query access for autonomous agents                                |
| Enterprises                | Self-hosted, SLA-controlled access to blockchain data                                  |

## The Subgraph Network

The Graph is an indexing and query protocol for blockchain data. One of The Graph's products are Subgraphs, which open APIs that extract, process, and store blockchain data so anyone can query it. Through The Graph protocol, the Subgraph Network is the decentralized set of independent Indexers who sync those Subgraphs and serve those results to end consumers.

The network hosts [15,000+ published Subgraphs across dozens of chains](https://thegraph.com/explorer), including high-demand ones like Uniswap, ENS, and Lido. With [Graph Horizon now live](https://thegraph.com/blog/horizon-upgrade-live/), The Graph protocol has generalized into an open marketplace of interchangeable data services: the Subgraph data service is the first, and the payment rails in this documentation (Graph Tally and Horizon Escrow) are the same ones future services will use.

A Subgraph Gateway lets a service provider put all of this to work under their own brand. Consumers send GraphQL queries to a gateway endpoint, and it discovers which Indexers can serve each one, routes to the best candidates, returns the response, and pays the Indexers it used. It is not strictly required (as consumers can query Indexers directly), but since individual Indexers are independent operators that may slow down or drop offline at any time, a Gateway absorbs that variability to maintain higher quality of service (QoS) while handling per-query payment.

For an Operator that runs data infrastructure (like an RPC provider, analytics platform, wallet backend, AI data service, or any product that resells or embeds blockchain data), running a Subgraph Gateway offers their customers managed access to The Graph Network under the Operator's own authentication, billing, and service level agreements (SLAs).

## Why Providers Run Subgraph Gateways

### Enable Vertical Integration of Data Services

A Gateway is not only cheaper than running an Operator's own indexing stack, it changes what an Operator can offer. Because a Gateway owns authentication, routing, payment, and QoS, a service provider can integrate The Graph Network into a full product stack: pair network data with their own APIs, add their own auth and rate limits, bundle Subgraph access with adjacent services, and present one endpoint and one bill to their customers. An Operator controls the consumer experience end to end while the network absorbs the cost and complexity of indexing. This vertical integration, owning the customer relationship while outsourcing the indexing, is the core commercial advantage of operating a Gateway.

### Leverage 15,000+ Public Blockchain Data APIs

Running a Gateway gives service providers and their customers query access to every published Subgraph on The Graph Network, including the high-demand, hard-to-maintain ones, without having to stand up and babysit that indexing infrastructure directly. For most teams, the alternative is running Graph Node (or equivalent) for every protocol they want to support, each with its own archive node, sync time, re-org handling, and ongoing maintenance. A Gateway replaces that with a single integration point in front of infrastructure that already exists on the network.

### Support More Indexed Chains

The Graph Network indexes Subgraphs across dozens of chains, and that coverage grows as new chains are integrated. Routing through a Gateway means Operators can support more chains for their customers without operating a node on each one: as The Graph adds chain support, Gateway Operators can serve those Subgraphs through the same endpoint. This lets a service provider expand multichain coverage at the speed of the network rather than the speed of their own infrastructure buildout. An Operator is not limited to the chains already integrated, either: an Operator that needs a new chain can help drive its integration onto the network, covered in [Chain Integrations](/gateways/subgraphs/ecosystem/chain-integrations/).

### Offset Indexing Infrastructure Costs

Indexing popular protocols is expensive and operationally heavy: archive nodes, storage, sync times measured in days, and around-the-clock reliability engineering. By routing to Indexers who already run that infrastructure, a Gateway converts a large fixed infrastructure cost into a usage-based query cost. Operators pay Indexers for the queries they actually serve, settled as efficient micropayments through Graph Tally rather than a per-query on-chain transaction. To learn more, see [Pricing & Payments](/gateways/subgraphs/consumer-side/pricing-payments/).

### Curate Common Data through Collections

Most consumers do not want the full surface area of 15,000+ Subgraphs. Instead, consumers typically want the handful that matter to their product, presented simply. [Subgraph Collections](/gateways/subgraphs/consumer-side/subgraph-collections/) let a Gateway Operator group and curate a chosen set of Subgraphs for end users, reducing complexity and turning raw network access into a tailored data product. Offering curated, common data (the pools, names, and balances an Operator's customers actually query) is a clear advantage over an unfiltered view of every Subgraph on the network.

### Enabling Blockchain Data for Humans _and_ Agents

A Gateway authenticates requests with either API keys (best for humans and applications) or x402 pay-per-query in USDC (best for autonomous AI agents that pay as they go with no account). One piece of infrastructure serves both audiences. See [Serving Queries](/gateways/subgraphs/consumer-side/serving-queries/).

### Eliminating Single Points of Failure

Queries are served by a decentralized set of Indexers rather than one hosted backend, and responses can carry attestations backed by Proof of Indexing (POI) and Fisherman dispute resolution. A Gateway can select multiple Indexers per query that fails over automatically, so no single Indexer outage takes down the Operator's service.

## What Subgraph Gateway Operators Run

Running a Gateway means running a small set of services and managing a few wallets. At a high level these components include:

- [**Graph Gateway:**](/gateways/subgraphs/components/overview/) routes queries, discovers and selects Indexers, and signs payment receipts.
- [**Indexer Selection:**](/gateways/subgraphs/components/indexer-selection/) the mechanism that picks the best Indexers per query.
- [**Graph Tally:**](/gateways/subgraphs/components/graph-tally/) the payment layer (receipts, RAVs, on-chain settlement) plus the aggregator and escrow-manager services a Gateway Operator runs.
- [**Titorelli:**](/gateways/subgraphs/components/titorelli/) an optional data-science service that aggregates a Gateway's Kafka output.
- [**Operations:**](/gateways/subgraphs/components/operating-a-gateway/) wallets, escrow funding, configuration, authentication, and monitoring.

## How Graph Gateway Docs Are Organized

This documentation is split into the two sides of a Gateway plus the shared components and ecosystem context.

- [**Components:**](/gateways/subgraphs/components/overview/) the internals of a Subgraph Gateway, how a query flows through it, and how to deploy one.
- [**Consumer-Side:**](/gateways/subgraphs/consumer-side/overview/) everything facing the developers and consumers who use a Subgraph Gateway, including pricing, query routing, collections, publication, and support.
- [**Supply-Side:**](/gateways/subgraphs/supply-side/overview/) everything facing the Indexers who serve an Operator's queries, including routing, escrow, sync incentives, and quality of service.
- [**Ecosystem Contributions:**](/gateways/subgraphs/ecosystem/chain-integrations/) how operating a Gateway connects back to the broader Graph ecosystem, including Graph Node and chain integrations.
