Refresh token expiration: discussion thread

[ThePodfather]

Hey everyone, I've created this thread to provide more insight on an upcoming change to how refresh tokens work for apps on the Spotify Web API.

We've shared a blog post that explains what's changing and why. The short version: refresh tokens will now require reauthentication after 6 months. Once expired, your app will need to send the user through the sign-in flow again to get a new one. Please use this thread to share any thoughts or questions about this change.

What's changing

• Refresh tokens will expire 6 months from when the user originally authorized your app
• An expired token will return invalid_grant from the token endpoint
• Refreshing an access token does not reset the 6-month clock
• This only affects Authorization Code and PKCE flows, not Client Credentials

 

Timeline

• New apps: effective now
• Existing apps: effective from July 20th, 2026

 

What you need to do

• Handle invalid_grant on token refresh by discarding the token and redirecting the user to sign in again
• Don't retry a failed refresh
• Test your reauth flow before July 20, 2026 to avoid disruption for your users

We'll do our best to answer questions in this thread, but we're not in a position to respond to every reply individually. Where appropriate we'll add updates to this post to ensure visibility to everyone. If related questions or discussions pop up elsewhere in the community, we'll link or merge them back here so everything stays in one place.

Thanks for taking the time to share your thoughts.

[vlipper]

What is the HTTP status code when the error with "invalid_grant" is returned?

[AdamusEsq]

So, just to clarify, how does this work for PKCE?

I might be misremembering this, but the last time I used PKCE, the refresh token retrieved from initial authorization was single use. You would then get a new refresh token the next time you attempt a refresh.

In that case, if an app is continually refreshing and receiving new refresh tokens, does the user still have to reauthorize after six months regardless? Or does the six‑month window apply only if the current refresh token isn’t used within six months?

[thlucas]

This change will be an inconvenience to Home Automation users (specifically Home Assistant), as it relies on automatic token refresh at specified 6 month intervals.  This change will force the user to re-authenticate every 6 months, upon which they will forget WHY this is happening as well as HOW to refresh the token.  That means more questions will be directed at ME (the author of the HA SpotifyPlus integration) to walk them through it.  From MY perspective, it's a maintenance nightmare, as there will be continuous questions / complaints / support for your changes!

Why do you guys (Spotify) keep taking away functionality for Premium account holders?!  And yet you keep raising monthly subscription prices for premium memberships!  

I am seriously considering dropping my Premium membership after this change - it's not worth the maintenance headaches that I will have to deal with for the 8,409 users that have my integration installed for Home Assistant.

[ohnoesman2]

This change renders my app basically useless 😞 I had spent thousands over the years funnelling users to Spotify for my app and now this is going to stop. I get why they did it but I think 6 months is way too short for the refresh tokens and 1 month's notice is brutal as I'll need to basically redesign the website and all the ads around this

[jlaf1976]

"Don't retry a failed refresh" this will add some 429 or 403 or a retry-after from api backend or something ? Cause my code deal with at least one retry before call what was asked, because i'm sorry to say that the auth flow from spotify sometimes become so erratic that if not at least one retry is done we are going to lead users to login page at least 5 times a week... 

[noelnoelnoel]

Yep I feel like if you want to impose changes at a month's notice and not lose all your apps, some clarity on this kind of thing is essential.

I started getting 403s that appear to be rate limits in disguise 2 years ago, worked around it but never found out why.

And needless to say topics like https://community.spotify.com/t5/Spotify-for-Developers/Persistent-429-Error-for-Personal-App-in-Dev... are routinely ignored.

[jlaf1976]

Why create a thread that no one at Spotify side is going to answer ?

[treerttr]

---

@vlipper wrote:

What is the HTTP status code when the error with "invalid_grant" is returned?

---

"invalid_grant" will be returned with an HTTP 400 Bad Request.

[vlipper]

I figured as much. It would have been nice to see this in the documentation as well. 

[rheschner]

Hi, I'm responsible for a home automation system with several thousand devices deployed, many with Spotify Connect integration through the Web API. I understand and respect the privacy goal of having access re-confirmed periodically. But as written, this change creates serious problems for the home automation segment, and I'd like to raise a few concerns and questions.

1) The behavior for existing authorizations is unclear. Will authorizations already older than six months fail on July 20, 2026? Or will the six-month clock start counting from July 20 for existing apps (expiring around January 2027)? Please clarify this explicitly, the difference between "everything breaks on a single day" and "we have a six-month runway" is the difference between an emergency and a manageable migration. Either way, one month of notice is far too short for a breaking change at this scale. At least six months would be needed for the code changes, deployment, and proactively notifying every end user before they're affected.

2) In home automation, playback is often not phone-initiated. In our systems a track frequently starts from a sensor event or a wall keypad, not from someone actively using their phone. When the token expires the user has no option to correct it and the integration simply fails silently. In many cases, the integration was set up by a third-party company, resulting in a high volume of support requests for these partners.

3) A six-month lifetime for the refresh token is too short for "set it up once" integrations. Users won't remember to re-link. At least one year would significantly reduce the damage. Please consider providing a channel to request a review or an extension for special cases (for example hardware/automation integrations) to postpone these deadlines, or, ideally, to preserve the previous behavior for established integrations.

Thank you for considering these issues. I hope we can work together to avoid them.

[thomk]

It feels like Spotify is just slowly trying to annoy developers into no longer creating apps with their API. Besides the high requirements for apps to get extended quota and the deprecation of many useful fields and requests from their API they are now planning to annoy users who use third party apps as well.

Six months is too short. This creates a frustrating experience for users from websites like Last.fm, which was previously a set-and-forget service that would just work correctly forever. You are essentially forcing 80-90% of their active userbase to re-authenticate twice a year, which will cause gaps and continuity issues in their listening history. I don't feel like the impact for third parties was thought through very well at all, especially considering the one-month notice. 

Why are there no exceptions for large extended quota apps or for apps like Last.fm and Discord that have exclusive access to the websocket/firehose API? Why hasn't Spotify considered the load of support requests and issues this will cause for partners? Why isn't there a better way for users and apps to extend the validity of their tokens to ensure continuity without disruptions? Most users and developers will notice only notice this after the change is applied and the damage is done.

Please consider at least delaying this change and extending the expiration timeframe so it's less destructive.

Edit: You can read here that Last.fm is struggling to respond in time because this change was announced on such a short notice: https://support.last.fm/t/important-change-to-spotify-scrobbling-spotifys-new-refresh-token-policy/1...

[Deadend1]

As an end user (aka non developer who uses 3rd party integrations like last.fm) this is infuriating. Spotify is really just destroying their service with all of these changes, and if this continues I'm not sure i'll be resubbing when my year is up. I dont want to have to keep on top of this every 6 months. We have enough stuff to keep on top of. Is spotify going to make my life easier or make its more frustrating. Seems you guys are simply just making the user experience worse with every idiotic change you shove down our throats. It'll be simply easier to just cancel Spotify and switch to one of the countless other music streaming services that dont create unnecessary friction. It would be nice if you guys rethink this latest disaster but I'm not sure anyone there is even reading this. 

[mavpulse]

Its not fair to push this to customers and integrators with little notice. Its also not reasonable to not allow their user to opt into a service for a longer period. This defeats the purpose of set it and forget it.

[enslaved2die]

I basically build a small CLI App because your own Daily Drive sucks. Now youre telling me a CLI app that runs headless needs a massive change so it can send a notification so I can reauth.
Its running inside a cron job 4 times a day so it gives me the current news, a cron job can open a browser... Thanks for that useless change

[elefunks]

I speak for all of us last.fm users: we don’t want to reconnect the damn thing every 6 months. The only reason I haven’t switched up to better platforms with lossless audio and better design is because I can easily scrobble music. Try changing that and you’ll lose many subscribers.