Skip to content
Get help on Slack

Different methods of querying data in Sanity.io and the use of read tokens to access private documents.

8 replies
Last updated: Jan 12, 2021
Hello! Is there any reason I would get different results between these two methods of querying data?

curl <https://xuaf19yr.api.sanity.io/v1/data/query/production>\?query\=\*%5B_type%20%3D%3D%20%22articlePage%22%5D%20%7B%0A%09...%0A%7D

const sanity = require('@sanity/client')

const sanityClient = sanity({
  projectId: 'xuaf19yr',
  dataset: 'production',
  useCdn: false,
})

await sanityClient.fetch(`
  *[_type == "articlePage"] {
    ...
  }
`)
Any help appreciated!
Jan 12, 2021, 10:01 AM
Actually, I do get the same result!
Jan 12, 2021, 10:04 AM
However, locally using "Vision" in Studio I'm getting the result I am expecting. I am probably missing something here.
Jan 12, 2021, 10:05 AM
What's the result you are not getting that you'd like to get?
If it's something like including 
drafts.<id>
documents in your results, this will require a read token as these documents are on a so-called non-root path (they have a 
.
in the ID) and therefore private even in a public dataset.
To set up a read token, go to your project on
manage.sanity.io , then to Settings and API. You should see an option there to add a new token. If you create a read token, you can then add it to the client configuration as follows:
const sanityClient = sanity({
  projectId: 'xuaf19yr',
  dataset: 'production',
  token: '<SANITY_READ_TOKEN>'
  useCdn: false,
})
Jan 12, 2021, 10:11 AM
Thank you for your reply
user M
! Using a token I'm getting the results I'm expecting!
Jan 12, 2021, 10:12 AM
Very helpful and a huge load off my shoulders!
Jan 12, 2021, 10:12 AM
Glad to hear! Was there anywhere you checked in the documentation and expecting to find this information? Just in case we can make it more visible 🙂
Jan 12, 2021, 10:14 AM
I’m not sure to be honest, I encountered this while using the seemingly excellent https://github.com/LiamMartens/sanity-plugin-intl-input . The plugin namespaces translated documents using i18n.&lt;id&gt;, which explains the issue. Maybe it would be a good idea for the plugin author to mention this somewhere in the plugin documentation, I’ll mention it when closing the issue I opened regarding this.
Jan 12, 2021, 10:39 AM
Thanks Jacob, that's great feedback indeed. I think Liam (the plugin's author) is considering adding the option to either use non-root paths or the former notation that put the i18n info at the back of the ID without a 
.
. Feels like a good opportunity to add the note you suggested alongside the option itself 🙂
Jan 12, 2021, 10:46 AM

Sanity– build remarkable experiences at scale

Sanity is a modern headless CMS that treats content as data to power your digital business. Free to get started, and pay-as-you-go on all plans.

Get started for freeExplore the demo

Was this answer helpful?