@sohambasu963draftchecks…fix/spotify-feb2026-migration → master3 files · +15 −15updated 8h agoSpotify's February 2026 Web API migration removed the /users/{user_id} endpoint family. Three actions still call them and 403/404 for every user (Spotify offers no managed auth config, so all Spotify users hit this):
| Action | Old (removed) | New |
|---|---|---|
SPOTIFY_CREATE_PLAYLIST | POST /users/{user_id}/playlists | POST /me/playlists |
SPOTIFY_GET_USER_S_PLAYLISTS | GET /users/{id}/playlists | GET /me/playlists |
SPOTIFY_GET_USER_S_PROFILE | GET /users/{id} | GET /me |
/tracks variant April 29 (auto-closed to support); get_playlist_items is already on /items on master — these three were the stragglers.Endpoint paths + empty path_params; user_id request fields become optional and documented deprecated/ignored so existing callers don't hit validation errors. Post-migration these endpoints only ever operate on the authenticated user — which is all the old ones effectively allowed anyway. action_identifier strings intentionally unchanged (stable registry identity).
Per the migration guide, these actions also reference now-removed endpoints and deserve a follow-up sweep: get_new_releases, get_several_browse_categories, get_single_browse_category, get_category_s_playlists (browse family — removed, no replacement), get_artist_s_top_tracks (removed), get_several_tracks (batch GET /tracks removed → per-id). Happy to file that as a second PR (likely deprecations rather than remaps).
py_compile passes on all three files; no schema-breaking changes (fields loosened, never removed).
🤖 Generated with Claude Code