Graph API Tester for GraphQL Endpoints

Send GraphQL queries and mutations straight from your browser, add the headers your API needs, run introspection to explore the schema, and read a formatted JSON response with the HTTP status, response time and size. Direct by default — your endpoint and tokens stay on your device; an optional proxy mode handles CORS-blocked APIs.

Direct by default — nothing leaves your device

Endpoint & headers

Your GraphQL API URL and optional HTTP headers (for example your auth token).

The request goes straight from your device to the endpoint. Nothing leaves your machine.

Query & variables

Query on the left, optional JSON variables on the right. Tab works, Ctrl/Cmd+Enter sends.

Response

Status, time and size of the response — plus the formatted JSON body.

Status—
Time—
Size—
No response yet. Add an endpoint above, write a query and hit “Send”.

Schema explorer

History

100% local — nothing leaves your device

What a Graph API tester is and when you need one

A Graph API tester is a small workbench for talking to a GraphQL API without writing a line of client code. You give it an endpoint, an optional set of headers, a query, and it shows you exactly what the server sends back. That sounds modest, but it removes an enormous amount of friction. Instead of scaffolding a fetch call, wiring up state and reloading an app just to see whether a field exists, you type the query, press send and read the answer in a second.

The situations where this pays off are everywhere in day-to-day development. You are integrating a third-party GraphQL service and want to know what its schema actually exposes. A query in production is returning null and you need to reproduce it in isolation. A backend colleague just shipped a new mutation and you want to confirm the arguments before touching the frontend. In each case a dedicated tester is faster and cleaner than the alternatives, and it keeps the experiment out of your codebase.

GraphQL vs REST, briefly and concretely

REST gives you a set of URLs, one per resource, and each returns a fixed shape. Ask for a user and you get the whole user object, whether or not you needed all of it; to also get that user’s posts you often make a second request to a second endpoint. GraphQL flips this: there is a single endpoint, and the client describes exactly the fields it wants — including nested relationships — in one request. You ask for a user’s name and the titles of their last five posts, and you get precisely that, no more.

The practical consequences are real. GraphQL tends to reduce over-fetching and the number of round-trips, which is why it is popular on mobile and data-heavy UIs. In return it moves complexity to the server and changes how you debug: the HTTP status is almost always 200, and errors live in the response body rather than in the status code. A tester that understands this — that surfaces the errors array as loudly as the data — saves you from staring at a green “200 OK” while a query silently fails.

Three different things called “graph”: GraphQL, Microsoft Graph, Facebook Graph

Searches for “graph api” collide three unrelated technologies, and it is worth being clear which one this tool is for.

  • GraphQL is an open query language and runtime specification, originally from Facebook but now governed independently. Any server can implement it. This is what the tester above is built for.
  • Microsoft Graph is a specific REST API from Microsoft that unifies access to Microsoft 365 data — mail, calendar, OneDrive, Teams, Entra ID users. Despite the name, it is not GraphQL; it uses ordinary REST paths like /v1.0/me/messages and OData query parameters.
  • Facebook (Meta) Graph API is Meta’s own REST-style API for Facebook, Instagram and related platforms. Again, not GraphQL — the “graph” refers to Meta’s social graph of people and objects.

This tester speaks GraphQL. You can technically point it at a REST endpoint since it just sends a POST, but the query editor, introspection and schema explorer only make sense for a real GraphQL server. If you are working with Microsoft Graph or the Meta Graph API, a general REST client is the better fit.

Building queries, mutations and variables

A query reads data. Its shape mirrors the shape of the response: you nest the fields you want inside curly braces, and the JSON that comes back has the same structure. For example, asking a countries API for { country(code: "DE") { name capital } } returns an object with exactly a name and a capital.

A mutation changes data — creating, updating or deleting — and looks almost identical, just prefixed with the mutation keyword. It usually returns the object it just modified so you can confirm the result in one round-trip.

Variables keep dynamic values out of the query string. Instead of pasting an ID into the query text, you declare it in the operation (query Country($code: ID!)), reference it as $code, and supply the value as a small JSON object in the variables panel: { "code": "DE" }. This is the pattern you should use in real code too — it is cleaner, avoids quoting mistakes and is safe against injection. The tester keeps the two in separate editors for exactly this reason.

Authentication: bearer tokens and API keys

Most GraphQL APIs are protected. The common pattern is a bearer token: add a header named Authorization with the value Bearer eyJhbGci…. Others use a custom header such as x-api-key. You obtain these from the provider’s developer dashboard, an OAuth flow, or a settings page in the service you are integrating. Add as many header rows as you need in the first step. Because every request is made locally by your own browser, pasting a token here does not expose it to us — though it is always good hygiene to use a token with the narrowest scope and shortest lifetime that still lets you test.

Common errors and what they actually mean

A 400 or 401/403 status means the HTTP request was rejected outright: malformed JSON, a wrong endpoint, or invalid credentials. Fix the request or the auth header. A 200 with an errors array is the GraphQL-specific case — the request ran, but a field failed validation, a resolver threw, or you asked for something you are not permitted to see. You often still get partial data alongside the errors, which is why reading only the status is misleading.

A CORS or network failure is different again: the browser never got a usable response, usually because the server does not allow cross-origin requests from this page. This is a genuine limitation of any browser-based tester, and we address it honestly below rather than pretending it away.

Direct or proxy? Two modes, and when to use each

The tester offers two request modes, and you switch between them with the toggle above the query editor. Direct (browser) is the default: every request goes straight from your browser to your endpoint, with no backend of ours in the path, no CDN caching your responses and nothing logged. Your Authorization headers, bearer tokens and the data that returns stay on your machine — open the browser’s network panel and you will see a single request, to your own API and nowhere else. When privacy matters most, keep this mode.

The catch with any browser-based tester is CORS: a page on getmind.io may only read a cross-origin response if that server sends an Access-Control-Allow-Origin header. Many production APIs do not, so a direct request fails even though the API is perfectly healthy. That is exactly what the second mode fixes.

Via our proxy forwards your request through our own small server, where the browser’s CORS rules do not apply, so CORS-blocked endpoints work. If a direct request fails, you do not even have to hunt for the switch: the error offers a “Retry via proxy” button that re-sends the identical query in one click. The honest trade-off, shown as a permanent warning whenever proxy mode is on, is that the endpoint, your headers and therefore your tokens travel through getmind.io in this mode. We keep that trustworthy the only way that counts: our proxy logs nothing — not the URL, not the headers, not the request or response body — only anonymous success/error counters. It also refuses to reach internal or private addresses, so it can never be turned into a tunnel into a network. Even so, prefer a short-lived or narrowly-scoped token when you use it. Use Direct for anything sensitive; reach for Proxy when an endpoint blocks CORS and you just need it to work.

Frequently asked questions

What is a Graph API tester?

It is a tool that lets you send a request to a GraphQL endpoint and read the response without writing any client code. You paste the endpoint URL, add any headers your API needs, write a query, hit send and see the JSON that comes back — along with the HTTP status, how long it took and how big it was. It is the fastest way to check whether an API works, explore what data it exposes and debug a query before you wire it into an app.

Is this tool free and does it require an account?

It is completely free, with no sign-up, no account and no usage cap. Every part — the query editor, introspection, the schema explorer, history and the cURL export — is available to everyone. There is no premium tier hiding the useful features.

Does my endpoint, token or response get sent to your server?

In the default Direct mode, no. The request goes straight from your browser to the endpoint you typed — nothing touches our infrastructure, and you can confirm it in the browser network tab. There is also an optional Proxy mode for endpoints that block CORS: when you choose it (or click “Retry via proxy” after a CORS failure), the request is forwarded through our server, so the endpoint, your headers and any tokens do pass through getmind.io. We log none of that — no URL, no headers, no body, only anonymous counters — and the tool shows a permanent warning while proxy mode is active. Direct mode stays the default precisely so you decide when anything leaves your device.

What is the difference between GraphQL, Microsoft Graph and the Facebook Graph API?

They share the word "graph" but are different things. GraphQL is a query language and specification for APIs — you describe exactly the fields you want and get back precisely that shape. Microsoft Graph is a specific REST API from Microsoft for Microsoft 365 data (mail, calendar, Teams, users); despite the name it is not GraphQL. The Facebook (Meta) Graph API is Meta’s own REST-style API for its platforms, also not GraphQL. This tester is built for GraphQL endpoints. It can still fire a POST at the others, but their request and response formats are different, so treat it as a GraphQL tool first.

Why do I get a CORS error, and can you fix it?

CORS is a browser security rule: a page on getmind.io can only read a response from another domain if that domain explicitly allows it with an Access-Control-Allow-Origin header. Many APIs do not allow browser requests from arbitrary origins, so a Direct-mode fetch fails even though the API itself is fine. You can fix it right here: switch to Proxy mode, or click “Retry via proxy” on the error — the request then runs through our server, where CORS does not apply, and it goes through. The trade-off is that in proxy mode the endpoint, headers and tokens travel through getmind.io (we log none of it). If you would rather keep everything local, test CORS-blocked APIs from the provider’s own console, a server-side script, or with a browser extension that relaxes CORS during development.

How do I authenticate a request?

Most GraphQL APIs use a bearer token. Add a header with the name Authorization and the value "Bearer YOUR_TOKEN". Some use an API key in a custom header such as x-api-key. You get these credentials from the API provider’s dashboard or developer settings. Because everything stays local, it is safe to paste a token here — but as with any tool, use a scoped or short-lived token when you can.

What does the introspection button do?

It sends the standard GraphQL introspection query, which asks the API to describe itself: every type, field, argument and enum it exposes. The result is rendered as a browsable schema explorer so you can see what you are allowed to query without reading external docs. Note that some production APIs disable introspection for security — if that button returns an error, that is why.

What is the difference between a 400 error and a 200 response with an errors array?

A 400 (or other 4xx/5xx) status means the HTTP request itself was rejected — malformed JSON, a bad endpoint, or auth failure. A 200 response with a top-level "errors" array is very GraphQL-specific: the request was accepted and executed, but something went wrong for one or more fields (a validation error, a resolver throwing, a permission issue). GraphQL often returns partial data alongside those errors. This tester highlights the errors array separately so you notice it even when the status says 200 OK.

Can I test queries, mutations and variables here?

Yes. Write any operation in the query editor — a query to read data, or a mutation to change it. Use the variables panel for a JSON object of values, and reference them in your operation with $name. Keeping variables separate from the query is the recommended pattern: it is cleaner, safer against injection and matches how you would call the API from real code.

Does the tool store my history?

It keeps your last ten requests in your browser’s localStorage so you can restore them with one click. That data lives only on your device and never gets uploaded. Clear it any time with the Clear button, or by clearing site data in your browser.

🧭 Building the frontend that will consume this API? Our guide to dynamic routes in Next.js covers how to wire data-driven pages cleanly.

🧰 More from the toolbox: the Core Web Vitals test measures how fast the app around your API actually loads, and the Markdown generator helps you document your queries. Both free, both privacy-friendly.

Requests are made with the browser’s native fetch. The demo endpoint used in the examples is the public countries.trevorblades.com GraphQL API, which needs no key and allows cross-origin requests — handy for a first test before you point the tool at your own endpoint. For endpoints that block CORS, switch on proxy mode and the request is forwarded server-side instead.