GraphQL API queries debugging

GraphQL Playground Guide: Test Queries, Variables, and Schemas

Learn how to run GraphQL queries with variables and headers, inspect responses and schema types, and turn successful requests into reproducible cURL commands.

· Mohammed Aquib Ansari

A GraphQL request combines several moving parts: an endpoint, a document, optional variables, and request headers. When a request fails, isolating those parts is faster than debugging them inside a full application. The ByteKiln GraphQL Playground keeps them visible together and generates a cURL request you can reuse outside the browser.

Only send data to an API you trust. Unlike ByteKiln’s local formatters, running a GraphQL request necessarily transmits the query, variables, and headers to the endpoint you enter.

Begin with the smallest query

Start with one field and add complexity after it succeeds:

query Viewer {
  viewer {
    id
    name
  }
}

GraphQL returns only requested fields. If the server responds with an error, read both the HTTP status and the response body. Many GraphQL servers return HTTP 200 even when the errors array contains resolver or validation failures.

A typical response has either data, errors, or both:

{
  "data": {
    "viewer": {
      "id": "42",
      "name": "Asha"
    }
  }
}

Use the JSON Formatter when you need to examine or compare a large nested payload separately.

Move changing values into variables

Avoid interpolating user input directly into the query text. Declare variables in the operation:

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

Then provide JSON variables:

{
  "id": "42"
}

Variables preserve types, make the query reusable, and avoid quoting mistakes. The ! means the server requires a non-null value. A variable validation error happens before the resolver runs, which helps distinguish a malformed request from application behavior.

Add headers carefully

Authenticated APIs commonly expect a bearer token:

{
  "Authorization": "Bearer YOUR_TOKEN",
  "X-Request-ID": "playground-test-001"
}

Use a short-lived development token with minimal permissions. Do not paste production credentials into screenshots, bug reports, shared machines, or source control. If you need to inspect a JWT’s expiry and claims first, use the JWT Decoder and remember that decoding does not prove a token’s signature is valid.

Browser requests are subject to CORS. A request can work through a backend service or cURL and still fail in the playground if the API does not allow the ByteKiln origin or the requested headers. That is a browser security policy, not a GraphQL syntax failure.

Read schema information as a contract

When the endpoint permits introspection, the Types panel can expose object types, fields, inputs, enums, and nullability. Use it to answer precise questions:

  • Is the argument named id or userId?
  • Does a field return a list?
  • Is an input required?
  • Which enum values are accepted?
  • What nested fields can be selected?

Some production APIs disable introspection. In that case, use the provider’s checked-in schema or API documentation. Introspection being unavailable does not mean the endpoint is broken.

Diagnose partial failures

GraphQL can return partial data alongside errors. Suppose one field requires an extra permission:

{
  "data": {
    "user": {
      "id": "42",
      "email": null
    }
  },
  "errors": [
    {
      "message": "Not authorized to read email",
      "path": ["user", "email"]
    }
  ]
}

Inspect path to identify the failing field. Nullability determines whether the failure stays at that field or propagates upward and nulls a parent object.

Reproduce the request with cURL

After a request works, copy the generated cURL command. It is useful for a bug report, CI smoke test, or comparison outside browser CORS. Remove secrets before sharing it. A reproducible request should capture the operation, variables, content type, and only the headers required to demonstrate the behavior.

A practical testing sequence

  1. Confirm the endpoint with a minimal query.
  2. Add variables and verify their JSON types.
  3. Add authentication using a limited test credential.
  4. Expand one selection level at a time.
  5. Inspect both data and errors.
  6. Review available schema types when introspection is enabled.
  7. Copy a sanitized cURL command for documentation or automated tests.

The playground accelerates exploration, but durable API confidence comes from checked-in queries, typed clients where appropriate, and integration tests that cover authentication and error behavior.