Product Decisions This Supports

Feature feasibility for new Spotify integrations: v3.0.0 aligns the package with Spotify’s current Web API surface, so roadmap items should not assume access to removed capabilities such as recommendations, related artists, featured/category playlists, genre seeds, audio analysis, or audio features for new Spotify apps.
Build vs. buy / adopt vs. wrap: For Laravel products needing straightforward Spotify authentication and API access, this package can reduce integration effort versus building and maintaining a custom client. However, teams must account for major-version upgrades and upstream API deprecations.
Dependency lifecycle planning: The v3 break indicates active maintenance but also confirms that Spotify API changes can force product-level changes. PMs should budget for periodic dependency upgrades and API contract reviews.
Existing-product risk management: Products already relying on removed endpoints should pin to v2 while evaluating alternatives, because v3 removes those methods entirely. New products should start on v3 and design around the reduced API scope.
Migration scoping: Renamed facades and removed aliases (Spotify, SpotifyClient) create a predictable but mandatory code migration. This supports decisions about upgrade timing, regression testing, and release coordination.

When to Consider This Package

Consider it when you are building a Laravel application that needs a lightweight, idiomatic Spotify Web API wrapper and you are comfortable with community-maintained packages.
Consider it when your product is a new Spotify integration and does not depend on the endpoints removed in v3.0.0, such as recommendations, audio features, audio analysis, related artists, category/featured playlists, or genre seeds.
Consider it when your team wants facade-based access and is willing to follow major-version upgrade guides, including updating imports to Aerni\Spotify\Facades\Spotify and Aerni\Spotify\Facades\SpotifyClient.
Look elsewhere or stay on v2 when you maintain an existing application that still relies on the removed Spotify endpoints and cannot migrate yet. v3 is explicitly not a drop-in replacement for those use cases.
Look elsewhere when you need guaranteed long-term vendor support, a broader Spotify SDK, or abstraction over multiple music providers. This package tracks Spotify’s API closely, so upstream deprecations become your upgrade work.
Treat as higher risk when your release process cannot tolerate breaking changes, or when Spotify API access is core to revenue and requires a formal support contract.

For executives: This package is a practical Laravel integration layer for Spotify, but v3.0.0 is a breaking release driven by Spotify API deprecations. New products can use it, but existing products relying on removed Spotify capabilities must either stay on v2 or plan a migration.
For engineering: Upgrade requires removing calls to deprecated methods, deleting any SpotifySeed usage, and updating facade imports. The changes are well documented, but they are mandatory and should be tested against real Spotify app credentials, especially for newly created Spotify apps.
For product: Do not plan new features around recommendations, audio features, audio analysis, related artists, or similar removed endpoints unless Spotify confirms availability for your app. Validate assumptions early, because this package now mirrors Spotify’s reduced API surface.
Recommendation: Adopt v3 for new Laravel/Spotify work that fits the supported API scope. For existing products, pin to v2 until a product decision confirms the removed endpoints are no longer needed, then schedule the facade and method migration as a planned breaking-change release.