Format a GraphQL Response

GraphQL is fundamentally different from REST when it comes to error handling, and that difference trips up many developers new to the technology. In REST, an error means a non-200 HTTP status code. In GraphQL, errors are part of the response body alongside successful data — the server almost always returns HTTP 200, even when something went wrong. Understanding the GraphQL response envelope is therefore critical for writing correct client-side error handling. This example demonstrates what a partial success looks like in GraphQL: the user query returned a valid user with their posts (data.user), but the avatar field resolver failed because the user's avatar URL is null. GraphQL includes both the data it successfully resolved and an errors array describing what went wrong. A client that only checks for the presence of a data field would silently miss the error; correct handling requires checking the errors array even when data is present. Key parts of the response explained: the data field contains the successful part of the response, mirroring the shape of your GraphQL query. The errors array holds one or more error objects, each with a message describing what went wrong, a path array showing exactly which field in the query caused the error, and a locations object pointing to the line and column in the query document where the error originated. Real-world scenarios: a dashboard shows user profiles but some have missing avatar images — logging the raw GraphQL response reveals an errors array entry for each user with a null avatar, pointing to a resolver that doesn't handle null URLs gracefully. Or a mutation appears to succeed (no JavaScript-level error thrown) but the database wasn't actually updated — inspecting the response JSON shows an error entry that the client code ignored. Tips for debugging: always log the complete response including the errors array during development. In Apollo Client, the errors field is available alongside data in query results. In plain fetch calls, always check response.errors after response.data. To use this example: paste your own GraphQL API response to see the full structure formatted, or use it as a reference when writing error handling code.

{
  "data": {
    "user": {
      "id": "usr_99",
      "name": "Alex Chen",
      "posts": [
        { "id": "p1", "title": "Getting Started with GraphQL" },
        { "id": "p2", "title": "Optimising Resolvers" }
      ]
    }
  },
  "errors": [
    {
      "message": "Cannot read field 'avatar' on null",
      "path": ["user", "avatar"],
      "locations": [{ "line": 4, "column": 5 }]
    }
  ]
}