Discussion about expiration of Sanity Auth tokens causing issues with API calls and deployment

Hey there - do the Sanity Auth token have an expiration date, since the migration? Did there change anything? We have major problems because of expiring or suddenly expired Auth tokens?

I don’t believe this has changed recently. To my knowledge, personal tokens have always been regenerated any time someone logs in (i.e., runs

sanity login

), invalidating the previous token in the process. Robot tokens (i.e., those generated under the API tab in Manage) should persist until deleted by someone on the project with sufficient permissions. [Edit: corrected in follow-up below.]

If this is a robot token (created in Manage), please let us know the name of the token and the project ID and we can investigate.

Hi user N. We did hear from our back end team that a user token will in fact expire even without a log out/login. For typical accounts, this is after one year. For SAML SSO, it will be a lot shorter. However, this is not related to any Studio changes or migrations and has been this way for a while. We will add this point of clarification to the docs.

No, it is not a robot token. And we never experienced an expiration before. And the problem with the robot tokens is, that the robot tokens are on project level and not on account level. We are happy to upgrade to any plan as needed to have this behavior again. To be clear: this new behavior completely destroys our business model. And this is definitely a new behaviour as we did not change anything related to this issue. I would be very happy to have a talk with one of your developers together with my lead developer to find out the reason for our issues as soon as possible, as our product is now useless.

I understand. I’ll wait for you to let me know your project ID and the name of the token (sending that over DM is fine), which gives us something to bring back to our team.

Okay, thank you for clarifying that. We’d be interested to know a bit more about how it’s impacting your business model. If you want to DM me your project ID, that would also help us investigate.

user N I think I need more context from you since the GH links you provided are not about the same issues you seem to be seeing here. Could you be more clear about what the issue is exactly?
(for ref:
https://github.com/sanity-io/sanity/issues/3975#issue-1498244950 ,
https://github.com/sanity-io/sanity/issues/3925#issue-1471583275 )

(btw. We are engineers here)

Sure, no problem. We are deploying automatically NextJS applications connected to a Sanity instance. This worked very well till the second week of december. Since then something changed and a sanity login renders all before used tokens invalid and our API calls are not longer possible. The issue is similar, because we often encountered the session unauthorized error in that case, although the one issue tackles a situation where sanity deploy I guess is performed through github actions and we are doing that in a similar way. Not github actions, but similar. We are working right now with the sanity-cli v.2.34 - and I think it could be that there are incompatibilities with the sanity v3 or something in this direction.

Our product is right now working. But one sanity login will destroy it.

okay, wait this seems a bit all-smashed-into-one:If you use V3 you will also need the compatible sanity dependency versions.

When you talk about tokens and sessions, these are separate when it comes to CLI build commands and Sanity Logins.

Please tell me what versions for sanity you use (package.json) and which commands you tried.

We use the following sanity versions "@sanity/core": "^2.35.0", "@sanity/dashboard": "^2.30.0",
"@sanity/default-layout": "^2.35.2",
"@sanity/default-login": "^2.35.2",
"@sanity/desk-tool": "^2.35.2",
"@sanity/eslint-config-studio": "^2.0.1",
"@sanity/vision": "^2.24",, and the sanity-cli version 2.34.0

Okay good to see you’re only in V2 not mixing 🙂Lets tackle the next question:
You tried to login via the cli in your terminal right?

Yes exactly.

And?

I can login. This is no problem. But, when I login a new token is created, that renderes the previous token useless.

But your session token is not the token used for deployment, it should only verify you as a user.Can you please share the errors you see?

When we logged in again, we see the "Unauthorized - Session does not match project host" in our builder - that used the session token. Which token should we use on user level for deploying?

For deploying several projects - the deploy token for one project is not usable for us as we have to upgrade the sanity projects on bulk sometimes - and for that we need a deploy token on user level.

okay interesting, I talked to the backend teams and turns out this is not a bug, its a loophole that you were able to use until you needed to create new session tokens.
API tokens is what you would need to use in the future though if you don’t want this to happen again (session tokens are going to be even shorter lived long term I’m afraid).

I know this must be frustrating, but for security reasons, we need to do so.There are ways to bulk deploy changes though, depends a bit on your needs in the end, which way we tackle this.

Is there a way to set up an API token via HTTP-API?

of course! you mean without the CLI?

and to get the token back as well? Later, after creation

Yes, without the client - but with the client is fine as well - we just need the possiblilty

I mean the CLI not the client (misspelled)

Yes, just with an HTTP request

But with the js-client woult be fine as well.

A pitty that it's not working anymore and a at least a deploy token on user level would be great. Thanks for your help.

It never “worked” you just were using a token with a limited live time until now

You can file a feature request though 🙂

Thanks - will do 😁

Ah and another thing: there is a token specially for deployments

Yes I saw it, so we need the token for the deployments and read write access I guess, right?

How long will be the lifetime of the session tokens?