Hi Spotify Web API team,
I am developing an application that utilizes the "Add Items to Playlist" endpoint:
POST /v1/playlists/{playlist_id}/items
One recurring problem is that the endpoint provides no way to prevent duplicate tracks from being inserted into a playlist when multiple requests come in close together or when the same track is requested repeatedly. In a typical application flow, the only safe option is to first read the playlist contents (paging through /playlists/{playlist_id}/items) and maintain a local cache of track IDs to avoid adding duplicates.
In practice, this approach has several drawbacks:
Playlists can be very large, so reading all items requires many paged requests.
Rebuilding or validating the cache (for example on app startup) can quickly trigger rate limits (429).
Even with caching, there is still a race condition: two concurrent requests can both pass the "not present" check before either add completes, resulting in duplicates.
While the snapshot_id field is helpful to detect that a playlist has changed, it does not fully solve the problem. If the snapshot_id differs from the cached version, there is no way to cheaply determine what exactly changed or where new tracks were inserted. As a result, applications still need to re-fetch the entire playlist to rebuild their cache. For very large playlists, this again requires many paged requests and brings back the same performance and rate limit concerns.
Feature request:
Could you consider adding an option to the Add Items to Playlist endpoint to support server-side duplicate prevention? For example:
A query parameter such as "ignore_duplicates=true" or "dedupe=true"
An idempotency key or de-duplication behavior scoped to a playlist
A mode where items are only added if not already present in the playlist
Ideal behavior:
When a track URI already exists in the playlist and a de-duplication flag is set, the API would skip inserting it, either silently or with a clear indication of which URIs were ignored.
The behavior should be atomic on Spotify's side to eliminate race conditions.
This would significantly reduce unnecessary API traffic, lower the risk of rate limiting, and simplify robust playlist management workflows without requiring full playlist scans and local caching.
Thank you for your consideration.
Edit:
Another way to achieve what I am after is having an endpoint that is similar to GET /v1/me/library/contains
That way we could at least check if that song is already in a playlist without having to cache the entire playlist.
