Can't reach Sanity API after standard init with blog preset

22 replies
Last updated: Jun 3, 2020
Okay, so started a new project just now and can't get it to work at all
Standard init
Used the blog preset

sanity start
works - no problembut when I try to go to the studio it just shows me this error:


An error occured while attempting to reach the Sanity API.

It might be that your internet connection is unstable or down. You could try hitting the Retry button to see if it was just a temporary glitch.
Any clues to what I can try to fix?
AI Update

This is a frustrating error but usually has a straightforward fix! The "An error occurred while attempting to reach the Sanity API" message typically points to a CORS configuration issue, not an actual API outage.

Here's what to try:

1. Add localhost to your CORS origins

Since you just initialized the project, your localhost development URL likely isn't whitelisted yet. You need to add it in your project settings:

  1. Go to manage.sanity.io
  2. Select your project
  3. Navigate to Settings → API → CORS Origins
  4. Click Add CORS origin
  5. Add http://localhost:3333 (or whatever port your Studio is running on)
  6. Important: Check the "Allow credentials" box
  7. Save

The "Allow credentials" checkbox is crucial - without it, you'll still get CORS errors even with the origin added.

2. Use sanity dev instead of sanity start

In modern Sanity projects (Studio v3+), the recommended command is sanity dev, not sanity start. The dev command starts a development server with live reloading and better performance. Try:

npm run dev
# or
sanity dev

3. Check if it's actually an API issue

While rare, sometimes there are actual API issues. You can verify the Sanity API status at status.sanity.io to rule out platform-wide problems.

4. Try the CLI CORS command

You can also add CORS origins via the CLI:

sanity cors add http://localhost:3333 --credentials

The --credentials flag is equivalent to checking that "Allow credentials" box in the dashboard.

Why this happens

When you initialize a new project, Sanity doesn't automatically whitelist localhost URLs for security reasons. Your browser blocks the requests because the Studio (running on localhost) is trying to make authenticated requests to the Sanity API without proper CORS configuration.

The CORS settings you configure in the Management Dashboard control which domains can access your project data with credentials, so this is a necessary security step for any new project.

Give the CORS configuration a try first - that fixes this issue 99% of the time!

Show original thread
22 replies
...and to add to this: I also tried with another project, and I still get the same error
Are there any console errors? Could be that you need to add
<http://localhost:3333>
to CORS list:

sanity cors add <http://localhost:3333>
Are there any console errors? Could be that you need to add
<http://localhost:3333>
to CORS list:

sanity cors add <http://localhost:3333>
I'm getting the same problem. Both offline and online. I'm using the sanity.io/create based project for Gridsome (but also cross tested it with the gatsby one) on Netlify and it worked before. Both netlify and local cors are added on the sanity projects.
Had this problem for several hours yesterday already and it reappeared today. Both days it seemed to happen in the afternoon CEST / start of office hours PDT and remained like this for hours (yesterday until after midnight).

Is there any way to debug this?
Is this potentially an issue in the studio as present in the
sanity.io/create or an api endpoint thing?
Asking because cli operations like deploying graphql works
user J

No errors in the console

Tried with the
sanity cors add <http://localhost:3333>
but I only got the following erorr:

Conflict - Duplicate origin already exists for this project
Could you open the inspector and look at what errors you get in the log? and in the network pane, see what requests are failing?
Could you check the network requests? Are all of them returning 200?
user Y
I'm not the best friend with the network tab, so I might have misunderstood this, but:

4 are blocked
3 return 304
the rest return 200
Could you take a screenshot perhaps?
One sec!
...and a ton of other ones with the blob: prefix between
hopefully this was correct, otherwise tell me and I'll try to send something better!
do you by any chance run an ad-blocker or something?
uBlock OriginBut tried disabling it now, and still no success
Tried with Firefox and it works there
...and now I fixed it on Chrome!
Running Privacy Badger which thought the api call was a "potential tracker" and therefore disabled
Yeah - that sometimes happen. It might help to clean out the Sanity auth cookie
could this be the same case for you
user F
?
Thanks for the help!
So yeah, for me this is resolved, and let me know if there's any info or something (Browser/Plugin version, etc) that would benefit if I sent for future bugs and so on
Yupp, also Privacy Badger here.
Anyone an idea on which part of the contact to &lt;yourappid&gt;.
api.sanity.io and cdn.sanity.io triggers privacy badget to completely block it (red). For things like the sanity-gridsomee example running on netlify, this leads to not just the dashboard being blocked but the site itself opening without any image assets as the gridsome example keeps them in the CDN.
This is still an issue for me. A bit of a different case however. Hopefully it is alright if I piggy back this thread. I am running a Raspberry Pi as a dev server and I am having this issue. It is both on Chrome and Firefox (with Privacy Badger disabled). I have added Cors for the the local IP (192.168.1.214:3333) and also for http://0.0.0.0:3333 which used adding the --host=0.0.0.0 tag. Still trying to track down the issue but any direction would be appreciated.
Access to XMLHttpRequest at 'https://{}.<http://api.sanity.io/v1/versions{}|api.sanity.io/v1/versions{*}>' from origin 'http://192.168.1.214:3333 ' has been blocked by CORS policy: The value of the 'Access-Control-Allow-Credentials' header in the response is '' which must be 'true' when the request's credentials mode is 'include'. The credentials mode of requests initiated by the XMLHttpRequest is controlled by the withCredentials attribute.
Looks like I'm an idiot. Even though I created an entry for 192.168.1.214:3333 I didn't flip the Enable Authentication switch. That seems to have solved the issue.

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?