Difference between _id and id in Sanity GraphQL
_idand
idwhen using graphql?
When using Sanity's GraphQL API, there's an important distinction to understand about document identifiers:
_id is Sanity's native document identifier field. This is a system field required on all documents stored in the Content Lake. Every document in Sanity has an _id field that uniquely identifies it. You can define your own _id when creating documents, but if you don't provide one, Sanity will auto-generate it. This is the field you'll use when querying Sanity's GraphQL API directly.
id is NOT a field that Sanity's GraphQL API generates. Based on the official GraphQL documentation, Sanity's GraphQL API only exposes _id as the document identifier field.
However, you might encounter an id field if you're using third-party tools or frameworks that add their own abstraction layer over Sanity's data. For example:
- Gatsby with gatsby-source-sanity: The gatsby-source-sanity plugin creates an
idfield as part of Gatsby's internal node system for managing data in its GraphQL layer. Thisidis generated by Gatsby, not by Sanity. - Other source plugins or integrations may similarly create their own
idfields for their internal purposes.
In practice:
- When querying Sanity's GraphQL API directly, use
_id- it's the only document identifier field available - If you see an
idfield, you're likely using a framework or plugin that's adding its own layer of abstraction (like Gatsby), and thatidis specific to that tool's data management system
So the key takeaway: _id is Sanity's native identifier, while id (if present) comes from whatever framework or tool you're using to consume Sanity's data, not from Sanity itself.
Show original thread3 replies
Was this answer helpful?
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.