Getting rate-limited with Spotify Web API despite using hydration manager + caching

[callmejeffrey]

Hey all — I’m building a native iOS app that connects to the Spotify Web API to display audiobook metadata for books users already have saved in their library. We’ve implemented a hydration manager to avoid redundant API calls, but we’re still encountering rate limiting on /me/audiobooks and /audiobooks/{id} after relatively light usage (~5–10 calls per session).

Our setup includes:

• Refresh token flow for user auth

• Local caching of audiobook metadata by ID

• Sequential (not parallel) hydration requests

• A fallback flow that disables Spotify if rate limits are hit

Still, we’re getting hit with 429 Too Many Requests responses even after hours of no activity. We’d love to understand:

1. Are there published or known rate limit quotas for audiobooks endpoints?

2. Are certain endpoints or usage patterns more sensitive than others?

3. Is there a recommended strategy for batching, throttling, or prioritizing metadata fetches?

Any tips from the community or Spotify folks would be greatly appreciated — even anecdotal patterns or rate-safe workflows.

Thanks in advance!

[ribezaz · Accepted solution]

Welcome to the Spotify Community, it's great to have you here! 👋

Thanks for sharing your question in such detail — it's great to see such a well-structured use of the Web API, especially in a project focused on audiobooks!

Regarding your report, I took a look at the Spotify Web API documentation again to suggest some ideas:

1. Rate Limit Quotas — audiobooks endpoints

Spotify does not currently publish specific quotas per endpoint in the public documentation. However, based on community experience, endpoints related to the user's library (/me/*) and those involving protected media, such as audiobooks, tend to be more sensitive and respond with 429 Too Many Requests at relatively low rates (even 5-10 calls can be enough in short intervals).

2. Sensitive patterns or observed behaviors
Endpoints such as /me/audiobooks and /audiobooks/{id} seem to use combined limits per user/token and IP.

Even spaced calls can generate 429s if the API identifies “pattern scraping” or “excessive hydration” behavior.

After a 429, it is highly recommended to respect the Retry-After header and wait before trying again.

3. Recommended strategies

Here are some suggestions to minimize the risk of hitting rate limits:

Implement debounce + priority by actual need: only hydrate audiobooks that are visible to the user or whose metadata is incomplete in the cache.

Store last query timestamps by ID — and avoid requerying before a minimum time (e.g. 1h).

Progressive batching: instead of fetching all the user’s books at once, preload them partially and defer the rest until active interaction.

Fallback with optimistic caching: if the data is not available at the moment, render a “placeholder” version with minimal information until the call is possible again.

Extra tip
You can monitor and log the X-RateLimit-* headers (if they are present in the HTTP response), although not all endpoints provide them.

If you want, I can help you review your hydration manager logic or build an adaptive backoff scheme with examples in Swift/Objective-C (I don't know which one you are using haha).

Keep me updated,

Cheers,
ribezaz 💚

[callmejeffrey]

Thanks so much for all of this info. I'll begin implementing these suggestions and will follow up if we're still running into issues.

—Jeffrey

[ribezaz]

You're welcome! I'm here to help if you need anything 🙂

@callmejeffrey