GraphQL

Sanity.io has powerful APIs for querying, patching, and mutating data in the real-time content backend. In addition to our GROQ API, we also support deploying GraphQL APIs to query your content.

GraphQL APIs are deployed using our command-line interface. The command inspects your studio's schema definitions and generates a GraphQL schema that closely resembles it (type names have their first letter capitalized – bookAuthor becomes BookAuthor), then adds queries that allow you to find and filter for the documents stored in your Sanity dataset. To use GraphQL with your project, you need to make sure that you follow the strict schema conventions.

For each document type in your Sanity schema, two top-level query fields are added:

• all<TypeName> - used to fetch all documents of the given type. You can add additional filters, sorting, limits, and offsets. Read more about filters below.
• <TypeName> - used to fetch a specific document of the given type by specifying its document ID.

For each object and document type in your Sanity schema, an equivalent filter type is generated. This can be used to constrain which documents are returned for a given query, much like an SQL query.

Most fields in your schema type will have a corresponding field in the filter. For instance, a book schema type may have a title field, which would then have a title filter:

{
  allBook(where: {title: {eq: "A Game of Thrones"}}) {
    title
    author {
      name
    }
  }
}

{
  "allBook": [
    {
      "title": "A Game of Thrones",
      "author": {
        "name": "George. R. R. Martin"
      }
    }
  ]
}

In a similar fashion, the author field would also have a filter type:

{
  allBook(where: {author: {name: {eq: "George R.R. Martin"}}}) {
    title
    author {
      name
    }
  }
}

{
  "allBook": [
    {
      "title": "A Game of Thrones",
      "author": {
        "name": "George R. R. Martin"
      }
    },
    {
      "title": "A Storm of Swords",
      "author": {
        "name": "George R. R. Martin"
      }
    }
  ]
}

Which comparator functions exist depend on the field type. For instance, a number field will have the comparators eq, neq, gt, gte, lt and lte, while a boolean field will only have eq and neq.

In addition to filtering on a per-field basis, document types have additional filters available under the _ field: references and is_draft:

{
  allBook(where: {_: {references: "jrr-tolkien"}}) {
    title
    author {
      name
    }
  }
}

{
  "allBook": [
    {
      "title": "The Lord of the Rings",
      "author": {
        "name": "J. R. R. Tolkien"
      }
    }
  ]
}

For a full overview of the available filters, see the GraphQL filter reference section down below.

You can sort on multiple fields on your top-level documents. You can also sort on your nested objects.

{
  allBook(sort: [ { title: ASC }, { published: DESC } ]) {
    title
  }
}

{
  "allBook": [
    {
      "title": "A Game of Thrones",
      "author": {
        "name": "George. R. R. Martin"
      }
    },
    {
      "title": "The Fellowship of the Ring",
      "author": {
        "name": "J. R. R. Tolkien"
      }
    }
  ]
}

We support pagination in the form of the take and skip concept. Pagination can easily be achieved like this:

{
  allBook(limit: 10, offset: 10) {
    title
  }
}

{
  "allBook": [
    {
      "title": "The Two Towers",
      "author": {
        "name": "J. R. R. Tolkien"
      }
    },
    {
      "title": "The Return of the King",
      "author": {
        "name": "J. R. R. Tolkien"
      }
    }
  ]
}

The schemas for Sanity Studio are a bit more flexible than what GraphQL is able to represent. That means that we can't promise that you'll be able to deploy a GraphQL API without any changes to your Sanity projects. Therefore, you may have to do a few changes (usually these are backward-compatible and do not require any data migration).

You may find that “anonymous“ object types have to be given a name and declared in the top-level scope. Take this example:

// schemas/blogPost.js
import {defineType} from 'sanity'

export default defineType({
  name: 'blogPost',
  title: 'Blog post',
  type: 'document',
  fields: [
    // ... other fields ...
    {
      name: 'sponsor',
      title: 'Sponsor',
      type: 'object',
      fields: [
        {
          name: 'name',
          title: 'Name',
          type: 'string'
        },
        {
          name: 'url',
          title: 'URL',
          type: 'url'
        }
      ]
    }
  ]
})

In the code above, the sponsor field is an object type declared inline. This means it cannot be used outside of the blogPost type. This is not compatible with GraphQL – all object types have to be defined in a global scope. To fix this, you should move the sponsor declaration to a separate file and import it into your schema explicitly, then have the sponsor field refer to it by name.

Example:

// schemas/blogPost.js
import {defineType} from 'sanity'

export default defineType({
  name: 'blogPost',
  title: 'Blog post',
  type: 'document',
  fields: [
    // ... other fields ...
    {
      name: 'sponsor',
      title: 'Sponsor',
      type: 'sponsor'
    }
  ]
})

// schemas/sponsor.js
import {defineType} from 'sanity'

export default defineType({
  name: 'sponsor',
  title: 'Sponsor',
  type: 'object',
  fields: [
    {
      name: 'name',
      title: 'Name',
      type: 'string'
    },
    {
      name: 'url',
      title: 'URL',
      type: 'url'
    }
  ]
})

GraphQL APIs are deployed using the Sanity CLI tool. In the simplest case, running sanity graphql deploy in your Sanity Studio project folder is enough to get started - it will use the default settings and deploy the API to the project ID and dataset configured in your sanity.config.ts file.

Sanity also has the ability to deploy multiple APIs per project/dataset, and also allows you to configure other settings about the API. To do so, you will want to either edit or create a sanity.cli.ts file (or sanity.cli.js if you prefer to not use TypeScript) in your Sanity Studio project folder.

The configuration file should export a configuration object containing a graphql key, which is an array of GraphQL API definitions. Here is an example configuration file:

// sanity.cli.ts
import {defineCliConfig} from 'sanity/cli'

export default defineCliConfig({
  graphql: [
    {
      playground: false,
      tag: 'experiment',
      workspace: 'staging',
      id: 'schema-experiment',
    },
  ]
})

In the example above, we are telling the CLI:

• We do not want a playground to be deployed for this API.
• We want to use the custom tag "experiment", which allows us to deploy multiple different APIs for a single dataset.
• We want to use the workspace with the id "staging" from the studio configuration file. This allows us to use different project IDs, datasets, schemas and similar.
• We want the ID of this GraphQL API to be "schema-experiment". If multiple GraphQL APIs are defined, this lets us deploy specific ones by using the --api flag.

Running sanity graphql deploy from your Sanity Studio project folder will now deploy all of the configured APIs from the CLI configuration.

We also support deploying multiple endpoints of the GraphQL schema to the same dataset by using the tag option in the CLI configuration file. This tag will figure as the last segment in the endpoint URL. This will let you test schema changes without breaking existing applications. If you don't specify any tag, the tag will be default.

Since we provide a way to deploy multiple GraphQL endpoints, you can use this CLI command to list all your existing endpoints:

sanity graphql list

GraphQL APIs have the option to deploy a "playground". This is an interactive GraphQL user interface that will allow you to more easily run/test queries. This is handy for development, but might not necessarily be something you want to deploy in production - which is why it is configurable. Do note that users can still run an introspection query to discover the properties of the schema without the playground being deployed, however.

If you want to enable/disable this feature, it can be done by using the boolean playground flag in the GraphQL CLI configuration.

There are two endpoint URLs you can run GraphQL queries against. The first is against the API where all your content changes will be available immediately. The complexity of the query will of course add to the response time:

https://<yourProjectId>.api.sanity.io/v2023-08-01/graphql/<dataset>/<tag>

In most cases you want to run GraphQL queries against the CDN endpoint. It will typically result in faster queries (especially on high-volume sites), but it can take 15 to 30 seconds before changes are visible:

https://<yourProjectId>.apicdn.sanity.io/v2023-08-01/graphql/<dataset>/<tag>

Perspectives allow your GraphQL queries to run against an alternate view of the content in your dataset. You can set a perspective by adding the query parameter perspective to your request. The available options are:

• raw: The default option if no perspective is set. Returns drafts and published content side-by-side for authenticated requests.
• previewDrafts: Treats all draft documents and in-flight changes as if they were published.
• published: Excludes all unpublished changes from your results.

https://<yourProjectId>.api.sanity.io/v2023-08-01/graphql/<dataset>/<tag>?perspective=previewDrafts

Content Source Maps (CSM) is an open specification by Sanity that enables the embedding of source metadata with your content, and lays the foundation for powerful features such as Visual Editing.

To use CSM with GraphQL, add the query parameter resultSourceMap=true to your request.

https://<yourProjectId>.api.sanity.io/v2023-08-01/graphql/<dataset>/<tag>?resultSourceMap=true

The CSM metadata will then be returned in the sanitySourceMap extension in the response:

{
  "data": {
    "allPost": [
      {
        "title": "GraphQL CSM"
      }
    ]
  },
  "extensions": {
    "sanitySourceMap": {
      "documents": [
        {
          "_id": "75bbbd60-0aa9-4b20-9c00-0b40cb010ff6"
        },
      ],
      "paths": [
        "$['title']"
      ],
      "mappings": {
        "$['allPost'][0]['title']": {
          "source": {
            "document": 0,
            "path": 0,
            "type": "documentValue"
          },
          "type": "value"
        }
      }
    }
  }
}

Using our newly created utilities in the @sanity/preview-kit/csm subpackage, you can configure your GraphQL client to support Visual Editing.

Here's an example of how you might use the createTranscoder utility with the URQL GraphQL client to create an exchange:

import { Exchange, makeOperation, Operation, OperationResult} from 'urql/core'
import { map,pipe } from 'wonka'
import { createTranscoder } from '@sanity/preview-kit/csm'

const sanityVisualEditing =
  (): Exchange =>
  ({ forward }) => {
    const transcoder = createTranscoder('https://studio.url')

    const processIncomingOp = (operation: Operation): Operation => {
      if (operation.kind !== 'query') {
        return operation
      }

      const url = new URL(operation.context.url)
      url.searchParams.set('resultSourceMap', 'true')

      return makeOperation(operation.kind, operation, {
        ...operation.context,
        url: url.toString(),
      })
    }

    const processIncomingResult = (
      result: OperationResult
    ): OperationResult => {
      if (result.operation.kind !== 'query') {
        return result
      }

      if (!(result.extensions && result.extensions.sanitySourceMap)) {
        return result
      }

      const csm = result.extensions.sanitySourceMap
      const transcoderResult = transcoder(result.data, csm)

      result.data = transcoderResult.result
      return result
    }

    return (ops$) => {
      return pipe(
        forward(pipe(ops$, map(processIncomingOp))),
        map(processIncomingResult)
      )
    }
  }

This example uses createTranscoder, which returns a transcoder function that takes the data response and sanitySourceMap as arguments and applies stega-encoding to compatible fields.

Visual Editing can be used on any hosting with the installation and configuration of the @sanity/overlays package.

The GraphQL API generally has the same rules as the GROQ API – dataset visibility is respected. Authenticated users see only the documents they have access to.

However, keep in mind that the schema of your GraphQL is public, so all types and fields will be introspectable by anonymous users.

Mutations are not exposed through the GraphQL API, but rather through our powerful mutation API.

• Equals: field { eq: "" }
• Not equals: field { neq: "" }
• In: field { in: [ "apple", "banana", "pineapple" ] }
• Not in: field { nin: [ "apple", "banana", "pineapple" ] }
• Matches: field { matches: "" }

• Equals: field { eq: "" }
• Not equals: field { neq: "" }
• Greater than: field { gt: 42 }
• Greater than or equal: field { gte: 42 }
• Lesser than: field { lt: 42 }
• Lesser than or equal: field { lte: 42 }

• Equals: field { eq: 42.0 }
• Not equals: field { neq: 42.0 }
• Greater than: field { gt: 42.0 }
• Greater than or equal: field { gte: 42.0 }
• Lesser than: field { lt: 42.0 }
• Lesser than or equal: field { lte: 42.0 }

• Equals: field { eq: true|false }
• Not equals: field { neq: true|false }

The schema generator will generate filtering types for your documents. It will provide filtering options for most of the fields defined in your schema. On top-level documents, it provides some special filters which can be accessed through _.

• References: field { references: "jrr-tolkien" }
• Is draft: field { is_draft: true }

We unfortunately don't provide any filtering for your array fields, yet.

The schema generator will expose a <your-type-name>Raw field, which gives you all Portable Text content in raw JSON. It will not resolve references by default, but if you use one of our source plugins for Gatsby or Gridsome, there are arguments you can pass to resolve references.

Since the schema is generated in Node.js instead of in a browser environment, certain imported modules might cause issues. Things that reference the window in a global context are a prime example. If you encounter issues, we'd be interested in hearing which modules cause problems to see if we can work around them and invite you to reach out to us in our Slack channel.

When a GraphQL API has already been deployed and you want to deploy a new version, the Sanity CLI tool will generate a new API definition and compare it with the previously deployed version. If there are any changed that are considered breaking or dangerous, the CLI will warn and ask for confirmation before deploying. In a CI environment, the CLI will exit with a non-zero exit code and fail the build. You can use the --dry-run flag to only check for breaking/dangerous changes (eg not actually deploy), and the --force flag if you are absolutely sure you want to deploy even with breaking changes. The rules for determining breaking/dangerous changes is defined in the findBreakingChanges and findDangerousChanges of the graphql npm package. Note that this is currently considered an implementation detail and may change in the future.