This is in the docs. https://graphql.org/learn/serving-over-http/ https://graphql.org/learn/serving-over-http/ > [a] query might result in some data and some

This is in the docs. https://graphql.org/learn/serving-over-http/ https://graphql.org/learn/serving-over-http/ > [a] query might result in some data and some errors, and those should be returned in a JSON object of the form {data: {}, errors: [] } Also checkout https://github.com/kadirahq/graphql-errors https://github.com/kadirahq/graphql-errors which exposes a standard `path` field for each error, so the client has a standard way to know which part of the query resulted in an error. If a mutation fails, for example a bank withdrawal fails because of insufficient funds, that is not necessarily an "error". To quote "code complete": > Exceptions should be reserved for what's truly exceptional. I'd send a mutation like this: withdrawFunds($amount: 100, $currency: "USD") { didSucceed didOverdraft canRetry } The client can control exactly which field(s) to request, or simply fire & forget if it does not care if the transaction went through. If you change your mind later, you can add & deprecate fields, in the true spirit of graphQL. In the case you shove arbitrary error codes in strings, you lose the benefits graphQL brings, like tracking usage of a field, self documenting & introspection, solving for over/under fetching, and the ability to revise these codes without versioning your mutations.