Sending GraphQL requests

GraphQL endpoints do not need a different tool — they need the same workflow with a query editor where the body editor was. In SchemaClient, GraphQL is a mode on the request, not a separate app.

Switch the request to GQL

In the URL bar, flip the request type from REST to GQL and enter the endpoint URL. GraphQL APIs expose a single endpoint (usually /graphql), so the URL stays the same across every query — the query itself decides what you get back.

Write the query

The query editor takes standard GraphQL:

query GetUser($id: ID!) {
  user(id: $id) {
    id
    name
    email
    teams {
      id
      name
    }
  }
}

If the query declares variables, provide them as JSON in the variables editor:

{ "id": "42" }

Variables beat string-splicing values into the query — the same query works across environments and test cases, and you never create injection-shaped bugs while testing.

Send and read the response

Send works exactly like REST. Two GraphQL habits worth building from day one:

• Read errors, not the status code. GraphQL returns HTTP 200 OK even when the query fails — failures arrive as an errors array in the body. A green status line means the transport worked, nothing more. (This is the GraphQL flavor of why 200 OK is not enough.)
• Expect data and errors to coexist. A query can partially succeed: data holds what resolved, errors explains what did not.

Auth, collections and teams — unchanged

A GraphQL request saves into collections, syncs into shared workspaces, and authenticates with the same bearer/API-key/basic options as everything else. If your GraphQL API runs on your machine, the localhost tunnel exposes it like any other local server.

For the broader testing methodology — what to assert about GraphQL responses and how REST and GraphQL testing differ — see how to test a GraphQL API.