GraphQL API Explained: How to Find and Scrape One

What Is a GraphQL API?

A GraphQL API is a query language and runtime for APIs that exposes a single endpoint through which clients request exactly the data they need, described by a strongly typed schema. A GraphQL client sends a query (usually as a POST request) describing the shape of data it wants, and the server returns a response matching that shape.

This is the core of the graphql vs rest api distinction: REST organizes data around multiple endpoints, each returning a fixed payload for a given resource (/users/1, /users/1/posts), while GraphQL organizes data around a single endpoint and lets the client decide what fields come back. IBM's overview of GraphQL vs REST covers this well if you want the vendor-neutral technical framing. The GraphQL Foundation maintains the specification, and most production implementations sit on top of libraries like Apollo Client on the front end.

For anyone trying to pull data out of a website rather than build one, that difference matters immediately: a REST API often reveals its structure just by looking at the URL. A GraphQL api reveals almost nothing until you look at the request body.

Why So Many Modern Websites Run on GraphQL

Most GraphQL endpoints you'll encounter aren't public developer-facing APIs — they're internal APIs built to power a specific front end. A single-page application built with React, Vue, or similar frameworks will often ship with an internal graphql api that the client queries directly, shaped precisely around what each screen or component needs.

Teams adopt GraphQL for their front ends for a few concrete reasons: it avoids over-fetching (no more downloading a full user object when you only need a name and avatar) and under-fetching (no more chaining three REST calls to assemble one page). A single graphql endpoint can serve every view in the app, with each component specifying its own query. That's efficient for the team that owns the site — but for anyone outside the company, it means the "API" doesn't behave like a documented product. There's no public reference, no versioned endpoints, and often no expectation that anyone besides the site's own front end will ever call it.

That's exactly the situation Browsevra's audience runs into constantly: the data you want is there, structured and clean, sitting behind a single POST endpoint — you just have to go find it.

How to Find and Read a Site's GraphQL API

Finding a site's GraphQL endpoint is a devtools exercise, not a documentation search:

1. Open the browser's developer tools and go to the Network tab.
2. Filter by XHR/Fetch so you're only looking at requests the page's own JavaScript is making — not images, stylesheets, and static assets.
3. Interact with the page (scroll a feed, apply a filter, load the next page of results) and watch for POST requests to a path like /graphql, /api/graphql, or something similarly generic.
4. Click that request and inspect the payload. You'll typically see a query field with GraphQL syntax, a variables object with the specific parameters for that call, and sometimes an operationName.
5. Check the response tab to see the exact shape of the data coming back — this is your extraction target.

That payload is your map. Once you know the query structure and variable names, you can often replay the same request with different variables (a different page number, ID, or search term) to pull more data without touching the rendered page again. This is the fastest way to find a website's graphql api and understand what's actually being requested — no documentation required.

The GraphQL-Specific Obstacles You'll Hit

This is usually where a straightforward plan stalls. Four problems show up repeatedly:

Persisted query hashes instead of full queries. Instead of a query field with readable GraphQL syntax, you'll sometimes see an extensions object containing a persistedQuery field with a sha256Hash. The client isn't sending the query text at all — it's sending a hash that the server maps to a pre-registered query on its side. This is a common optimization (it saves bandwidth and lets the server whitelist accepted queries), but it means you can't just modify the query yourself; you either need to find where the full query was registered client-side or work within the exact shape the hash represents. Crawlee's writeup on reverse engineering the persistedQuery extension walks through this mechanism in detail.

Introspection disabled. GraphQL's introspection system normally lets you query the schema itself — every type, field, and query available — which is invaluable for exploring an unfamiliar API. Production endpoints routinely disable introspection to prevent outsiders from mapping the schema this way, so __schema queries return an error even though the API works fine for its intended queries.

Client-generated auth headers. A request captured in the network tab often carries a bearer token, signed timestamp, or session cookie generated by JavaScript running in the browser — not a static value you can hardcode. Replay the exact same request with curl an hour later and it fails, not because the query was wrong, but because the token expired or was tied to a session fingerprint your script never established.

Validation errors on "correct" queries. Even when you copy the query and variables faithfully, missing headers (referer, origin, a custom client-version header) can trigger a rejection before the query is even evaluated.

When You Need a Headless Browser to Reach the GraphQL API

Everything above assumes you can eventually send the request yourself with a plain HTTP client. Often you can't — not because you got the query wrong, but because the token, cookie, or hash your request needs simply doesn't exist until real JavaScript has executed in a real browser context. Bot detection systems are specifically built to catch HTTP clients that skip this step: no JS execution, no canvas fingerprint, no realistic timing between requests.

This is where headless browser graphql access earns its keep. Instead of reconstructing the auth flow by hand, you load the page in an actual rendering engine, let the site's own JavaScript run, and capture the network requests and responses as they happen — including the fully-formed GraphQL calls with valid tokens attached. If you want the mechanics of what's happening under the hood at that point, Browsevra's explainer on the browser rendering engine breaks down how a headless Chrome instance produces those JS-generated values in the first place, and the headless browsers overview is a good primer if the concept itself is new to you.

Once you've captured a valid, authenticated GraphQL call this way, you often don't need to keep rendering the full page repeatedly — you can replay the captured request pattern directly, refreshing tokens through the rendered session only when they expire. That combination — render once to get past bot detection and JS-generated auth, then extract efficiently from the response — is the practical middle ground between "just curl it" and "render every single page load." For the broader landscape of scraping methods and where this approach fits legally and technically, see Browsevra's guide to scraping website data.

Frequently Asked Questions

What's the actual difference between a GraphQL API and a REST API when you're trying to pull data from a site?

A REST API exposes multiple endpoints, each returning a fixed payload for a resource, so you can often guess the data shape from the URL alone. A GraphQL API exposes a single endpoint where the client specifies exactly which fields it wants in the request body, meaning the structure is invisible until you inspect the actual query payload rather than the URL.

How do I find the GraphQL endpoint a website is using under the hood?

Open your browser's DevTools, go to the Network tab, filter by XHR/Fetch, and interact with the page while watching for POST requests to a path like /graphql. Clicking that request shows the query, variables, and response shape, which together tell you exactly what data is available and how to request it.

Can I query a site's GraphQL API with a simple script, or do I need a browser?

It depends on whether the request's auth tokens, cookies, or query hashes are static or generated by client-side JavaScript. If they're static, a plain HTTP client can replay the request; if they're generated dynamically during page load or tied to bot-detection checks, you need a real rendered browser session to produce a valid request first.

Why does the GraphQL request I captured only show a hash instead of the full query?

That's a persisted query — an optimization where the client sends a SHA-256 hash referencing a pre-registered query on the server instead of the full query text. The server maintains a whitelist of accepted hashes, which both reduces bandwidth and limits which queries can be run against the endpoint.

Is querying a website's internal GraphQL API considered scraping, and is it legal?

Yes, pulling data from a site's internal GraphQL endpoint is a form of scraping, since you're programmatically extracting data the site didn't publish as a public product. Legality depends on factors like the data involved, the site's terms of service, and jurisdiction, so it's worth reviewing the fuller legal and methodological context before building anything at scale.

Does it help if GraphQL introspection is enabled on the target site?

Yes, significantly — introspection lets you query the schema itself to see every available type and field, which turns schema exploration from guesswork into a documented reference. Most production sites disable it deliberately to keep their internal API harder to map, which is why persisted queries and introspection restrictions tend to show up together.

Once you've mapped the query and found the endpoint, the remaining problem is almost always reachability: getting past auth tokens and cookies that only exist after JavaScript runs, without tripping bot detection along the way. Browsevra's docs show how to capture those rendered network requests and responses directly, and the pricing page is worth a look if you're weighing this against building your own rendering infrastructure. Start there, or head to browsevra to see the full picture.