Spotify pre-save link tools: the technical comparison

scope

A technical comparison of Spotify pre-save link tools, with the underlying OAuth flow walkthrough so you can evaluate vendors meaningfully. Pre-save is the music-industry workflow that lets fans authorize a release to be added to their Spotify library automatically when it goes live.

Cluster C hub: /guides/firebase-dynamic-links-replacement. Adjacent music-vertical page: /guides/best-music-smart-link-tools.

how Spotify pre-save actually works

The mechanism is not "Spotify holds a list of users who pre-saved." It's an OAuth-authorization-token-persistence pattern.

1. Fan visits a pre-save landing page hosted by a smart-link tool (or the artist's own server).
2. Page hosts a "Pre-save" button that initiates a Spotify OAuth authorization flow.
3. Spotify prompts the fan to grant the user-library-modify (and sometimes playlist-modify-public) scope to the requesting client.
4. The smart-link tool's server receives the OAuth access + refresh tokens and stores them.
5. On release day, the smart-link tool calls Spotify's Save to library API using the stored tokens for each pre-saved user, adding the new release to each user's library.

The smart-link tool is essentially a server-side cron job that fires Spotify API calls at release time using accumulated OAuth tokens.

the OAuth scopes involved

Required Spotify scopes for a pre-save:

Most pre-save flows request the minimum: user-library-modify. Aggressive flows that auto-follow the artist and add to playlists request more, which both raises consent friction and creates more trust burden.

the comparison table

Linkfire pre-save

Linkfire's pre-save is the industry default for major-label releases. Differentiators:

• Multi-DSP pre-save in a single flow (Spotify + Apple Music + Amazon Music).
• Geo-aware DSP prioritization — different markets see different default DSPs.
• Pre-save data syncs with major distributor and label CRM tools.
• High-volume capacity — handles release-day surges without rate-limiting issues.

Use when: you have a label release, expect significant pre-save volume, and need cross-DSP coverage.

ToneDen pre-save

ToneDen's pre-save integrates tightly with paid-acquisition campaigns. Often used for paid social campaigns that drive pre-save volume during the lead-up to a release.

Use when: pre-save volume is paid-acquisition-driven.

Feature.fm pre-save

Feature.fm competes directly with Linkfire on pre-save with comparable feature surface. Pricing often more accessible for mid-tier artists.

Use when: evaluating Linkfire and finding it overpriced for your release volume.

DIY pre-save

If you want to own the user data and don't want to pay a smart-link vendor, the DIY pre-save is buildable in a weekend.

Components:

# Flask example
from flask import Flask, request, redirect, session
import requests
import time

app = Flask(__name__)

CLIENT_ID = "your-spotify-app-client-id"
CLIENT_SECRET = "your-spotify-app-client-secret"
REDIRECT_URI = "https://yourdomain.com/presave/callback"
SCOPES = "user-library-modify"

@app.route('/presave')
def presave_init():
    return redirect(
        f"https://accounts.spotify.com/authorize?"
        f"client_id={CLIENT_ID}&"
        f"response_type=code&"
        f"redirect_uri={REDIRECT_URI}&"
        f"scope={SCOPES}"
    )

@app.route('/presave/callback')
def presave_callback():
    code = request.args.get('code')
    token_resp = requests.post(
        'https://accounts.spotify.com/api/token',
        data={
            'grant_type': 'authorization_code',
            'code': code,
            'redirect_uri': REDIRECT_URI,
            'client_id': CLIENT_ID,
            'client_secret': CLIENT_SECRET,
        }
    ).json()
    
    # Store the refresh_token for use at release time
    store_presave_user(token_resp['refresh_token'])
    return "Thanks! We'll add the release to your library on launch day."

def fire_presaves_at_release(album_id):
    """Run as cron at release time."""
    for refresh_token in get_all_presave_refresh_tokens():
        access_token = refresh_access_token(refresh_token)
        requests.put(
            f'https://api.spotify.com/v1/me/albums',
            headers={'Authorization': f'Bearer {access_token}'},
            params={'ids': album_id}
        )

The full implementation needs:

• Spotify Developer App registration (a few minutes at developer.spotify.com).
• HTTPS endpoint for the OAuth callback.
• Token storage (database).
• Cron job (or scheduled task) firing at release time.
• Rate-limit handling for release-day surges (Spotify's API allows generous rates, but a release with 100K pre-saves needs batched calls).

Spotify's Web API reference covers the full API surface.

Use when: you want full data ownership, have engineering time, and release volume justifies the build.

the in-app browser failure mode

Pre-save flows break in social-app in-app browsers more than any other deep-link surface. Reasons:

1. The Spotify OAuth flow opens in a pop-up by default. Pop-ups are suppressed in many in-app webviews.
2. The OAuth redirect requires returning to your origin domain. The host webview may navigate to the redirect URL inside itself rather than handing back to your page.
3. The user's existing Spotify login session is in Safari/Chrome's cookie jar, not the in-app webview's. Even if OAuth completes, the user gets re-prompted to log in.

Engineering breakdown of why this happens: /guides/in-app-browser-cookies-explained. Consumer-side problem: /guides/in-app-browser-logged-out.

The mitigation patterns smart-link tools use:

• Detecting in-app webviews and surfacing an "Open in browser" UI before initiating OAuth.
• Using full-page redirects instead of pop-ups.
• Falling back to email-based "remind me at release" flows when OAuth can't complete.

None of these fully solve it. Pre-save conversion from social-app traffic is materially lower than from native browsers.

Apple Music pre-add and Amazon Music

Pre-save isn't Spotify-only. Apple Music has a parallel mechanism via MusicKit JS / MusicKit native, and Amazon Music has a similar API.

Cross-DSP pre-save flows in tools like Linkfire and Feature.fm handle the per-DSP differences:

• Apple Music's MusicKit requires Apple Developer credentials and a different OAuth pattern.
• Amazon Music's pre-add is more recent and has rougher edges.

DIY cross-DSP is a meaningfully larger project than Spotify-only. Most teams that want multi-DSP pre-save buy a vendor for this reason.

release-day operational considerations

When firing pre-saves at release time:

1. Batch the API calls. Spotify's Web API allows ~50 albums per request via the PUT /me/albums?ids=... endpoint, but per-user calls scale linearly. For 10K pre-saves, that's 10K API calls.
2. Refresh tokens before use. Refresh tokens are long-lived but access tokens expire after an hour. Refresh-then-use is required.
3. Handle revoked tokens. Users who revoked your app's access between pre-save and release-day will fail with a 401. Don't retry these; log and skip.
4. Distribute the load. Firing all calls at the exact release timestamp creates a thundering-herd issue. Spread firing across the first 30–60 minutes after release.

The smart-link vendors handle this operationally. The DIY path requires planning.

related dev reading

• Music smart-link tools overview: /guides/best-music-smart-link-tools
• Cluster C hub: /guides/firebase-dynamic-links-replacement
• In-app browser problem (affects pre-save flows): /guides/in-app-browser-logged-out
• Cookie isolation mechanism: /guides/in-app-browser-cookies-explained

For non-music creator link infrastructure, the linkboo path is at link.boo/api.

references

• Spotify Web API documentation
• Spotify Authorization Guide (OAuth 2.0 flows)
• Apple MusicKit documentation
• Amazon Music API documentation