The PolyApiIDE GraphQL client runs as a Chrome, Edge and Firefox extension: the schema arrives through introspection, tokens and endpoints come from environments, and nothing gets installed on your machine.
GraphQL over HTTP is a single POST to an endpoint such as /graphql, carrying {"query": "...", "variables": {...}} and a Content-Type: application/json header. Any REST client can send that — but then the schema, the variables and the repeatability are your problem.
PolyApiIDE gives GraphQL its own workspace type, so operations, environments and response history live next to the other protocols of the same project.
The protocol type is set per workspace or per request. In a GraphQL workspace there is one address for the whole schema, and what changes is not the path but the operation text: queries, mutations, fragments. A GraphQL collection therefore looks nothing like a REST tree of URLs — it is a set of operations against one endpoint.
You need the schema so you do not have to memorise field names and argument types. There are two ways to get it: ask the server through introspection, or import an SDL file. Both are part of the free plan, alongside OpenAPI, WSDL, .proto and AsyncAPI import.
Everything else behaves as in a REST workspace: environments, variable hierarchy, auth, scripts, QA checks. Collections stay local in the browser, and nothing reaches the cloud unless you send it there through an export, a patch or a snapshot.
Set the protocol type on the workspace so every request inside inherits it, or switch the type on a single request. Put the endpoint in the address field — usually a single URL such as https://api.example.com/graphql.
Two options:
.graphql, .graphqls) — for endpoints where introspection is switched off.The second case is more common than people expect: disabling introspection in production is normal practice.
The operation text goes into the query field, arguments into variables. Named operations and fragments work as usual:
query User($id: ID!) {
user(id: $id) {
id
name
roles { code }
}
}
Keep the endpoint and the token in an environment and reference them with {{var}} or {var} — substitution works in the URL, the headers and the body. The hierarchy is request → collection → workspace → environment, and empty values are skipped instead of overwriting the layer below.
The response opens as a JSON tree. One GraphQL detail worth remembering: status 200 does not mean success — validation and resolver errors arrive in the errors array with a 200 status. Add request-level QA checks on JSON path and substring so those cases fail on their own.
| Scenario | PolyApiIDE | Playground / Sandbox |
|---|---|---|
| Getting started | Browser extension, no account needed to send requests | A page served by the service itself, or an external site |
| Schema | Introspection or SDL file import | Endpoint introspection |
| Where requests live | Collections and workspaces in local browser storage | Usually the tab and its local storage |
| Variables | Hierarchy: request → collection → workspace → environment | One set of variables per tab |
| Other protocols alongside | REST, WebSocket, SOAP, SSE, gRPC over JSON transcoding | GraphQL only |
Playground and Sandbox are fine when there is one open endpoint. Collections, several environments and repeatable checks are the job of an API client.
No. The Free plan works right after you install the extension, and sending requests needs no sign-up. An account is only used for cloud features and for a paid licence key.
Import the schema as a file — GraphQL SDL import is included in the free plan. You can also work with no schema at all: you write the body yourself and the extension sends it.
There is no dedicated subscriptions mode. You can open a two-way channel by hand in a WebSocket workspace and send frames yourself, but the extension will not assemble subscription operations from the schema. We say so plainly rather than let you hunt for the button.
That is how GraphQL over HTTP works: schema and resolver errors are returned in the errors array while the transport status stays 200. Read the body, not only the status — and add a QA check on JSON path so the case is caught automatically.
Yes, {{var}} and {var} expand in the body too, which covers both query and variables. Switching environments is enough to move between stages; the requests themselves stay untouched.