Why does the error template return HTTP 200 instead of an error status?

That is correct GraphQL behavior. Over HTTP, GraphQL servers conventionally return 200 even when resolvers fail, signalling failure through the errors array in the body rather than the status line. Clients that branch on status alone will miss these failures, which is exactly what this template helps you catch.

What is the difference between the validation error and the partial response template?

The validation error returns data: null with a GRAPHQL_VALIDATION_FAILED extension, representing a query rejected before execution. The partial response returns real data alongside an errors entry with a path, representing a query that executed but had one resolver fail — the case most clients handle badly.

Does it generate a schema or SDL?

No. This mocks the response side only: the JSON a client receives. It does not parse queries, validate them against a type system, or emit SDL. If you need query-aware mocking, a schema-driven tool that executes against your SDL is the right choice.

~/tools / 03 / graphql-query-response

GraphQL Response Mocker

GraphQL clients are picky: they expect a top-level data key, relay-style connections, and errors that carry locations and extensions. This tool speaks that dialect natively. Mock a healthy query result with nested edges, or a validation failure with a proper GRAPHQL_VALIDATION_FAILED extension code, and feed it straight to your client cache.

compose payload

template preset

status code latency (ms)

response body — live JSON editor

— validating —

exported mock url

—

▸ open mock ↗

simulated response headers

content-type: application/json

$ man graphql-mock

Everything above is encoded into the #data= fragment of the exported URL — deflated and base64url-packed by your browser. Fragments are never sent to any server, so this mock is shareable and private. Paste the URL anywhere: a teammate's browser decodes it identically.

cat ./tldr.txt

A GraphQL response mocker produces spec-compliant payloads — a top-level data object, relay-style edges and node connections, or an errors array carrying locations and extensions — so Apollo, urql, and Relay clients can be tested without a running schema.

./when-to-use-this

You need to verify your client renders a field-level error correctly while still displaying the partial data alongside it.
The schema is still being designed and you want to prototype the UI against the connection shape you expect.
You are testing cache normalization and need a response with stable ids and cursors.

./frequently-asked

Why does the error template return HTTP 200 instead of an error status?: That is correct GraphQL behavior. Over HTTP, GraphQL servers conventionally return 200 even when resolvers fail, signalling failure through the errors array in the body rather than the status line. Clients that branch on status alone will miss these failures, which is exactly what this template helps you catch.
What is the difference between the validation error and the partial response template?: The validation error returns data: null with a GRAPHQL_VALIDATION_FAILED extension, representing a query rejected before execution. The partial response returns real data alongside an errors entry with a path, representing a query that executed but had one resolver fail — the case most clients handle badly.
Does it generate a schema or SDL?: No. This mocks the response side only: the JSON a client receives. It does not parse queries, validate them against a type system, or emit SDL. If you need query-aware mocking, a schema-driven tool that executes against your SDL is the right choice.

GraphQL Response Mocker

cat ./tldr.txt

./when-to-use-this

./frequently-asked

grep -i related-searches

ln -s ./related-tools