Jun 9
Feature Request — Support merchant-provided paid Music Search APIs in the Music Player component
Hi Customily Team,
We'd like to submit a product request regarding the Music Player component: we hope the Customily backend can support selecting other paid music search APIs, not only the current Spotify API Credentials.
1. Current situation
The Music Player currently depends primarily on Spotify API Credentials (Client ID / Client Secret configured by the merchant). Spotify API Credentials management reference: https://developer.spotify.com/documentation/web-api/concepts…
2. Why this is a risk
Under Spotify's official Developer policy, commercial use of the Web API is explicitly restricted, and any commercial-scale use requires Extended Quota Mode — which is now very hard to obtain and uncertain in review. Evidence:
Spotify's Developer Terms place commercial use under a dedicated section, "IV. Streaming and Commercial Use."
→ https://developer.spotify.com/terms
Newly-created apps default to Development Mode. As of May 15th 2025, Spotify only accepts applications only from organizations (not individuals) for extended access.
→ https://developer.spotify.com/documentation/web-api/concepts… spotify
Extended access now requires a registered business, a launched service, and 250,000+ monthly active users. Spotify itself states over 95% of the applications we receive for extended Web API access fall short of basic requirements.
→ https://developer.spotify.com/blog/2025-04-15-updating-the-c… Spotify for Developers
As of February 2026, rules tightened further: Spotify is now limiting each app to only five users in development mode and requires the app owner to hold a Premium subscription.
→ https://techcrunch.com/2026/02/06/spotify-changes-developer-… TechCrunch
In short, a typical commercial POD store using the Spotify Music Player is, in practice, operating outside Spotify's permitted terms — a real compliance and continuity risk for both merchants and Customily.
3. Our proposal
We suggest Customily support a model similar to the Cutout API: let merchants purchase and configure their own paid music search API. Ideally:
A provider selector in the Music Player / Integrations settings (Spotify + one or more commercially-licensable music search APIs).
A field for the merchant's own API key/credentials — the merchant is responsible for purchasing/licensing.
The rest of the component (search field, title / artist / album art, scannable code) keeps working regardless of the selected provider.
4. Suggested alternative music APIs (similar functionality to Spotify: song / artist / album search + cover art)
For reference, here are some commercially-usable alternatives that provide the same core search-and-metadata capability:
Apple Music API (MusicKit) — large catalog, track/artist/album search, high-res artwork; commercial use via the Apple Developer Program. → https://developer.apple.com/documentation/applemusicapi
Deezer API — 90M+ tracks, search, artist/album metadata, album art and 30s previews. → https://developers.deezer.com
TIDAL API — public API with catalog access for album, artist, and track information. → https://developer.tidal.com
7digital API — B2B-oriented, supports metadata, streaming and music purchasing; explicitly built for commercial apps. → https://docs.7digital.com
Musicfetch API — single call returns links + metadata across 30+ services (Spotify, Apple Music, Deezer, etc.); good for cross-platform coverage. → https://musicfetch.io
Soundcharts API — standardized track/artist metadata across major platforms; B2B commercial licensing. → https://soundcharts.com/en/music-metadata-api
(Free/open fallback) MusicBrainz + Cover Art Archive — open music metadata + album artwork, no paid quota; useful as a no-license baseline. → https://musicbrainz.org/doc/MusicBrainz_API
This lets each merchant choose a stable, compliant, commercially-usable service, and significantly reduces the impact of future Spotify policy changes on the Music Player.
5. Request
Could you please evaluate whether this can be added to the product roadmap, and let us know whether there is an expected development timeline or a viable interim workaround?
Reviewing