`retry-after` header not accessible in web app

[schickling]

Problem

When building a web app using the Spotify API, it’s currently not possible to “back off” appropriately when hitting a 429 rate-limit response as suggested by the official docs. This makes it close to impossible to build browser-only web apps using the Spotify API.

As already pointed out by other Spotify API users the Spotify API currently doesn’t provide the `Access-Control-Expose-Headers: Retry-After` in API responses which (based on how CORS is implemented in browsers) means it’s not possible to access the `headers['retry-after']` value from within your browser application.

Note the issue mentioned above was incorrectly closed as the Spotify API only return the `Access-Control-Allow-Headers` header but not the required `Access-Control-Expose-Headers: Retry-After` header.

Also note this limitation only exists in a browser context and not e.g. with Node.js.

Solution suggestion

The Spotify API should add the `Access-Control-Expose-Headers: Retry-After` HTTP header to its responses.

[spotifyjosh]

Hi @schickling, thanks for the detailed feature request.

Are you seeing that the Access-Control-Expose-Headers header is missing even when your app has received a 429 status response from the Web API? If you are then it would be great to know more about the specific API endpoint(s) that your app is calling and we can dig into this further.

[schickling]

Yes, it's missing both in successful responses (e.g. 200 status) but more crucially it's also missing in the 429 status case.

This seems to happen for every API endpoint I've tried so far e.g. fetching albums via ` /v1/albums`.

[spotifyjosh]

Hmm, got it. So far I'm having trouble reproducing this with the Albums API. Could you share the header names that you do see on a 429 status code response from the albums endpoint? (Please be sure to not post any access tokens or the client secret key.)

[geoffreylitt]

Thanks for the response @spotifyjosh! I'm @schickling's collaborator.

Below is a link to a screenshot of a 429 response from the /tracks API in a browser. As you can see, the Access-Control-Expose-Headers header is not set on the response.

https://share.cleanshot.com/EWt2ce

[spotifyjosh]

Thanks for following up with this @geoffreylitt!. We're looking further into it now. Can you share your app's client ID as well — or a link to your app if it is public?

[geoffreylitt]

[EDITED 2022-10-13 21:08 UTC to fix a mistaken client ID]

Thanks for the response @spotifyjosh!

I recently switched client IDs and don't remember which one I used to take that screenshot. It's definitely one of these two IDs:

1e2e2dedd6e54539b5a2477c485077e8

853b69a3e5164ac1a8b360b5ca678d20

[jrmangel]

Hi, I'm having the same issue. I believe "Retry-After" needs to be added to the "Access-Control-Expose-Headers" response header so that I can access it, otherwise I have to just guess at how long to wait and end up getting rate limited even more. Thanks. My client id is 'e5dc68155dce45b8bbae5ce0ff45fc4a' and it's public at https://spotify-in-playlist-search.onrender.com/

[applepp]

I am running into the same issue. Any updates on this?

[sxvan]

This is still not fixed to date. Its a shame that the spotify web api developers dont add necessary headers for 8 YEARS which would probably take 10 minutes to implement.

[Stevercakes]

Please update the api to include the Access-Control-Expose-Headers if you want developers to actually use the retry-after response header for 429 responses

[SugarFreeManatee]

Still not fixed...

[izanaa]

Same problem for me...

[wergerfebt]

I'm also running into the same issue

[ol3q_key-k6xp]

Hello!

It has been 2 years, 1 month, 13 days, 4 hours, and 35 minutes and this problem has still not been fixed. 

It'd be great if we could get a resolution for this before 2030.

Thanks!

[tomjaimz]

This seems fine for me. Can you be more specific about the scenario in which you're not getting the 

access-control-expose-header value of retry-after?