How to Test GraphQL APIs with Custom Authorization Headers in Chrome

Most GraphQL tutorials assume you’re using Postman, Apollo Studio, or a dedicated GraphQL client. Those tools are fine for isolated API exploration — but they’re not your browser.

If your frontend app calls a GraphQL endpoint, the real test is what happens in Chrome, with the exact headers your app sends, against the same environment your users hit. That means you need to inject an Authorization: Bearer <token> header directly into your browser’s requests — without copying requests into Postman and losing the in-browser context.

This post shows how to do that with HeaderSnap.

The problem with testing GraphQL auth in the browser

GraphQL APIs typically use a single endpoint (usually /graphql) and rely heavily on HTTP headers for authentication and authorization. An unauthenticated request returns a 401 or a permission error buried in the response body. An authenticated request returns data.

When you’re testing in the browser, you need that Authorization header attached to every request hitting the GraphQL endpoint. The options most developers reach for:

Chrome DevTools: no way to inject headers into live requests without intercepting and rewriting them manually
Postman or Apollo Studio: isolated from your frontend app’s actual state — you’re not testing your app, you’re testing the API in a vacuum
Hardcoding tokens in the frontend: fine for local dev, bad practice, and you still need to remember to remove it

HeaderSnap adds a fourth option: inject the header once at the browser level, scoped to a URL pattern matching your GraphQL endpoint. It fires on every matching request your browser makes — including your app’s fetch calls — without touching your code.

Setting up a GraphQL auth header rule

Open the HeaderSnap popup and create a new rule:

Label (optional): GraphQL Auth — Staging

URL pattern: Target your GraphQL endpoint. If it’s at api.staging.yourapp.com/graphql, use a glob pattern:

api.staging.yourapp.com/graphql

Or to match any path under a domain:

api.staging.yourapp.com/*

You can also use a regex pattern for more precision — for example, matching multiple environments from one rule:

.*\.yourapp\.com/graphql

Header name: Authorization

Header value: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9... (your actual token)

Action: Set

Header Target: Request

Save the rule and enable it. Now open your app in Chrome and fire a GraphQL query. The Authorization header is attached to the request automatically — visible in the Network tab under the request headers for the matching URL.

Scoping rules to specific environments

If you’re testing across staging, QA, and production, the same token usually won’t work across all three. This is where HeaderSnap’s profiles feature makes the GraphQL testing workflow cleaner.

Create a separate profile for each environment:

Staging profile: rule targeting api.staging.yourapp.com/graphql with a staging JWT
QA profile: rule targeting api.qa.yourapp.com/graphql with a QA-scoped token
Production profile: rule targeting api.yourapp.com/graphql with a short-lived production token (useful for verifying behavior with a real token, not just auth bypass)

Switch between environments by clicking the profile tab. Only the active profile’s rules fire — no risk of sending a staging token to a production endpoint mid-session.

Testing headers beyond Authorization

Authorization is the most common use case, but GraphQL APIs often respond to other request headers:

API versioning. Some GraphQL backends use a custom header to select schema versions:

X-Api-Version: 2

Add that as a rule targeting the GraphQL endpoint. Enable it when testing against a specific version; disable it to fall back to default behavior.

Operation tracing. Headers like X-Request-Id or X-Trace-Id are often used internally to correlate GraphQL operations with server-side logs. You can inject a fixed trace ID while debugging a specific query to make it easier to find in your logs.

Bypass flags. During development, some backends accept a X-Internal-Dev: true header to skip rate limiting or return additional debug fields in responses. A rule scoped to your dev or staging endpoint keeps this confined to that environment.

Each of these is a rule in HeaderSnap — enable it for the session you need it, disable it when done.

Checking that the header is being sent

After setting up a rule, verify it’s working in Chrome DevTools:

Open DevTools → Network tab
Fire a GraphQL query from your app (or reload the page)
Find the request to your GraphQL endpoint
Click it → Headers → Request Headers

You should see Authorization: Bearer <your-token> listed. If the rule isn’t firing, check that the URL pattern matches exactly — the most common issue is a pattern that matches the domain but not the path, or vice versa. HeaderSnap’s URL pattern field accepts both glob (* wildcards) and regex patterns to cover different matching needs.

Why this beats the alternatives

Approach	Tests your actual app?	Survives page reload?	No code changes?
Postman / Apollo Studio	No	Yes	Yes
Chrome DevTools intercept	Yes	No	Yes
Hardcoded token in frontend	Yes	Yes	No
HeaderSnap rule	Yes	Yes	Yes

Postman is great for exploring an API. But when you’re trying to reproduce a bug your app has in production, or verify that a new permission model works correctly end-to-end, you want a real browser request from your running app — with the right headers attached.

That’s the gap HeaderSnap fills for GraphQL testing.