Which ID is the actual Sanity ID: "id" or "_id"?

4 replies
Last updated: Aug 25, 2020
when running sanity graphql quries, we end up with two ID's one is "id" and the other one "_id" . Does anyone know which one is actual sanity ID? I need the ID that will never change.
AI Update

The _id field is the actual Sanity document ID and is the one that will never change. This is the stable, permanent identifier for your document in Sanity's Content Lake.

When using Sanity's GraphQL API, you'll see both fields:

  • _id: This is the document field that comes directly from Sanity. It's stored as the _id attribute on every document and is a unique 128-character identifier (often a UUID like 189bc292-e41b-42a0-91b5-bfaa33a34af2). This ID never changes once set and is what you should use when you need a stable, permanent reference to a document.

  • id: This is a GraphQL-generated node ID. In some implementations (like when using Gatsby with gatsby-source-sanity), this is an auto-generated identifier created by the GraphQL layer itself, not by Sanity.

So if you need the ID that will never change and represents the actual Sanity document, always use _id. This is what you'll use for:

  • Creating references between documents
  • Querying specific documents via the API
  • Any operations that need to target a specific document in your dataset

The _id field is also what you'll see in the Sanity Studio URL and what's used throughout Sanity's APIs (GROQ, HTTP API, etc.). You can even set custom IDs when creating documents if needed, but once set, the _id remains constant for the life of that document.

Show original thread
4 replies
i think the graphql wrapper just pushes the _id into the id for graphql things
but i always use the _id because i also hybrid groq things for content previews in gatsby sites
_id is always on the sanity side
awesome thanks πŸ™‚

Sanity – Build the way you think, not the way your CMS thinks

Sanity is the developer-first content operating system that gives you complete control. Schema-as-code, GROQ queries, and real-time APIs mean no more workarounds or waiting for deployments. Free to start, scale as you grow.

Was this answer helpful?