Apple Music API for Developers: What You Can Build Beyond MusicKit in 2026

Table of Contents

• The Apple Music Developer Landscape in 2026
  • MusicKit JS vs MusicKit for Swift vs REST API
  • What Apple Exposes (And What It Doesn't)
• Building with the Apple Music API Through a Unified Layer
  • Authentication Without Managing Apple Developer Tokens
  • Reading User Libraries and Playlists
  • Code Example: Fetching Apple Music Playlist Tracks via MusicAPI
• Apple Music API Limitations and Workarounds
  • Rate Limits and Quota Management
  • Regional Availability and Content Restrictions
• Combining Apple Music with Other Services in One App
• FAQ

The Apple Music Developer Landscape in 2026

Apple gives developers three ways to interact with Apple Music: MusicKit JS for web apps, MusicKit for Swift on Apple platforms, and the REST API for server-side access. Each has different capabilities, different authentication requirements, and different trade-offs. Understanding the landscape is the first step toward building something that works across platforms and scales beyond Apple's ecosystem.

MusicKit JS vs MusicKit for Swift vs REST API

Apple splits its Apple Music developer API across three SDKs, and the feature overlap is not as clean as you would expect.

MusicKit JS runs in the browser. It handles user authorization through Apple's web OAuth flow, provides playback controls for Apple Music subscribers, and gives access to catalog search and user library endpoints. The catch: it is tightly coupled to Apple's JavaScript runtime and does not work in Node.js or server-side environments without workarounds.

MusicKit for Swift is the native SDK for iOS, macOS, tvOS, and watchOS. It offers the richest feature set: playback control, subscription status checks, local library access, and deep integration with Apple's hardware (CarPlay, HomePod). But it only works on Apple platforms. If your app targets Android or the web, MusicKit for Swift is irrelevant for those users.

The REST API (Apple Music API) is the server-side option. It supports catalog search, user library reads, playlist management, and recommendations. Authentication requires a developer token (a signed JWT using your Apple Developer account's private key) plus a Music User Token for personalized endpoints. The REST API works from any server, any language, any platform.

Here is how the three compare:

Feature	MusicKit JS	MusicKit Swift	REST API
Platform	Web browsers	Apple platforms only	Any server
Playback control	Yes (subscribers only)	Yes (full controls)	No
Catalog search	Yes	Yes	Yes
User library access	Yes	Yes	Yes (with Music User Token)
Playlist management	Limited	Full CRUD	Full CRUD
Recommendations	Yes	Yes	Yes
Auth method	Web OAuth + dev token	Native sign-in	Developer JWT + Music User Token
Offline support	No	Yes	N/A (server-side)
Cross-platform	Web only	Apple only	Any

For most developers building multi-platform apps, the REST API is the practical choice. It is the only option that works across web, mobile (including Android), and server environments.

What Apple Exposes (And What It Doesn't)

The Apple Music API covers the core operations most music apps need: catalog browsing, user library reads, playlist CRUD, and personalized recommendations. You can search the Apple Music catalog by song, artist, album, or playlist. You can read a user's library, fetch their playlists, and create new ones.

What Apple does not expose is significant:

• No streaming audio access. The REST API has no audio playback endpoints. You cannot stream tracks server-side or build custom players without MusicKit JS or MusicKit for Swift.
• No lyrics. Apple does not provide lyrics through any public API.
• No listening history. There is no endpoint for a user's play history or recently played tracks through the REST API.
• No social features. Apple removed its Connect social features years ago and never replaced them with API endpoints.
• No audio analysis. Unlike some services that expose tempo, key, and energy metrics, Apple provides no audio feature data.
• Limited webhook or event support. There is no real-time notification system for library changes or new releases.

These gaps matter when you are planning your app's feature set. If your product depends on play history, audio analysis, or server-side playback, you will need to supplement the Apple Music API with other data sources or services.

Building with the Apple Music API Through a Unified Layer

The Apple Music API works, but it comes with friction that slows down development. Token management is complex, response formats differ from every other streaming service, and you are locked into Apple-specific code. A unified API layer removes this friction and lets you build Apple Music features with the same code you use for every other service.

Authentication Without Managing Apple Developer Tokens

Apple Music API authentication is a two-step process that trips up even experienced developers.

First, you generate a developer token: a signed JWT using an ES256 private key from your Apple Developer account. This token identifies your app to Apple's servers. It expires, and you need to handle rotation.

Second, for any user-specific endpoint (library, playlists, favorites), you need a Music User Token. The user authorizes your app through MusicKit JS or MusicKit for Swift, which returns a Music User Token. This token cannot be refreshed. When it expires, the user must re-authorize.

Here is what that looks like in code:

// Step 1: Generate Apple Developer Token (server-side)
const jwt = require('jsonwebtoken');
const fs = require('fs');

const privateKey = fs.readFileSync('./AuthKey_XXXXXXXXXX.p8');
const developerToken = jwt.sign({}, privateKey, {
  algorithm: 'ES256',
  expiresIn: '180d',
  issuer: 'YOUR_TEAM_ID',
  header: {
    alg: 'ES256',
    kid: 'YOUR_KEY_ID'
  }
});

// Step 2: Get Music User Token (client-side, MusicKit JS)
await MusicKit.configure({ developerToken });
const music = MusicKit.getInstance();
await music.authorize(); // opens Apple sign-in
const musicUserToken = music.musicUserToken;

// Step 3: Make API calls with both tokens
const response = await fetch(
  'https://api.music.apple.com/v1/me/library/playlists',
  {
    headers: {
      'Authorization': `Bearer ${developerToken}`,
      'Music-User-Token': musicUserToken
    }
  }
);

That is three steps, two token types, one client-side dependency, and zero refresh capability for user tokens.

With MusicAPI's unified authentication, this collapses to one flow:

// 1. Initialize auth (server-side)
const authUrl = await fetch('https://api.musicapi.com/auth/init', {
  method: 'POST',
  headers: { 'Authorization': `Bearer ${MUSICAPI_KEY}` },
  body: JSON.stringify({ service: 'apple-music', callbackUrl: 'https://yourapp.com/callback' })
});
// 2. Redirect user to authUrl
// 3. Handle callback, receive a single token
// 4. Use that token for all Apple Music API calls through MusicAPI

No developer JWTs. No Music User Tokens. No client-side SDK dependency. One token that MusicAPI manages, refreshes, and validates for you. The same flow works for every other supported service.

Reading User Libraries and Playlists

Once authenticated, reading an Apple Music user's library through the direct API means dealing with Apple's response format. Playlists come back with nested attributes objects, relationships for tracks, and Apple-specific identifiers that do not map to any other service.

A direct Apple Music API call to fetch playlists returns this:

{
  "data": [
    {
      "id": "p.vkQMz9CLR8q07B",
      "type": "library-playlists",
      "href": "/v1/me/library/playlists/p.vkQMz9CLR8q07B",
      "attributes": {
        "name": "My Workout Mix",
        "description": { "standard": "Tracks for the gym" },
        "canEdit": true,
        "hasCatalog": true,
        "playParams": { "id": "p.vkQMz9CLR8q07B", "kind": "playlist" },
        "dateAdded": "2026-01-15T08:30:00Z"
      }
    }
  ]
}

Through MusicAPI, the same data comes back normalized:

{
  "playlists": [
    {
      "id": "p.vkQMz9CLR8q07B",
      "name": "My Workout Mix",
      "description": "Tracks for the gym",
      "trackCount": 24,
      "service": "apple-music",
      "url": "https://music.apple.com/playlist/..."
    }
  ]
}

Flat structure. Consistent field names. The same shape you get when fetching playlists from Spotify, YouTube Music, or Tidal. No attributes nesting, no Apple-specific object types. Your app code handles one data model. You can view the full normalized response format on the Apple Music playlist info page.

Code Example: Fetching Apple Music Playlist Tracks via MusicAPI

Here is a complete example that fetches tracks from an Apple Music user's playlist through MusicAPI. This same code works for any supported streaming service by changing the service parameter.

const MUSICAPI_KEY = process.env.MUSICAPI_KEY;
const USER_TOKEN = process.env.USER_TOKEN; // from MusicAPI auth flow

async function getPlaylistTracks(playlistId) {
  const response = await fetch(
    `https://api.musicapi.com/playlists/${playlistId}/tracks`,
    {
      headers: {
        'Authorization': `Bearer ${MUSICAPI_KEY}`,
        'X-User-Token': USER_TOKEN
      }
    }
  );

  if (!response.ok) {
    throw new Error(`MusicAPI error: ${response.status}`);
  }

  const data = await response.json();
  return data.tracks;
}

// Usage
const tracks = await getPlaylistTracks('p.vkQMz9CLR8q07B');

console.log(`Found ${tracks.length} tracks:`);
tracks.forEach(track => {
  console.log(`  ${track.name} — ${track.artist} (${track.album})`);
});

The response includes normalized track objects:

{
  "tracks": [
    {
      "id": "i.mQ91LZQS70YlPz",
      "name": "Blinding Lights",
      "artist": "The Weeknd",
      "album": "After Hours",
      "duration": 200,
      "service": "apple-music",
      "isrc": "USUG12000497"
    }
  ]
}

Compare that with the direct Apple Music API response, which nests everything under attributes, uses Apple-specific relationship links for artist and album data, and requires a separate API call to resolve the artist name from a relationship URL. MusicAPI flattens and resolves all of that in one call.

See the full track response structure on the Apple Music playlist tracks page.

Apple Music API Limitations and Workarounds

Every API has limits. Apple's are stricter than most streaming services, and the workarounds require careful planning. Understanding these constraints upfront saves debugging time later.

Rate Limits and Quota Management

Apple does not publish exact rate limit numbers for the Apple Music API. The documentation says requests are throttled "based on the key, the API endpoint, and the user." In practice, developers report being throttled after roughly 60 to 120 requests per minute per developer token, though this varies by endpoint.

What makes Apple's rate limiting harder to manage:

• No Retry-After header. When Apple throttles you, the response is a 429 status code with no indication of when to retry. You have to implement exponential backoff blindly.
• Per-endpoint variation. Catalog search endpoints seem to have tighter limits than library read endpoints, but Apple does not document the difference.
• Music User Token limits. User-specific endpoints may have separate per-user limits on top of the per-developer limits.

Compare this with other services where the rate limits are published, Retry-After headers are included, and the throttling behavior is predictable.

A unified API like MusicAPI handles this complexity internally. MusicAPI tracks per-provider rate limits, implements appropriate backoff strategies for each service, and exposes one clear rate limit policy to your application. If Apple throttles a request, MusicAPI retries it with the right delay so your app never sees a 429.

Regional Availability and Content Restrictions

Apple Music operates across 175+ countries, but catalog availability varies significantly by region. A track available in the US catalog might not exist in the Japanese catalog. Playlists curated for one region may be empty or unavailable in another.

The Apple Music API requires a storefront parameter for catalog endpoints. This is Apple's term for a region-specific catalog. You need to know the user's storefront to return relevant results:

GET https://api.music.apple.com/v1/catalog/{storefront}/search?term=taylor+swift

If your app serves users globally, you need to:

1. Detect or ask for the user's region
2. Map that to an Apple Music storefront code
3. Handle cases where content is not available in a storefront
4. Return meaningful error messages instead of empty results

This is another area where building against multiple services compounds the complexity. Every service handles regional content differently. Some use IP-based detection, others require explicit locale parameters, and the error behavior for unavailable content varies across all of them.

MusicAPI normalizes regional handling across services. You pass the user's context, and the API resolves the correct storefront, locale, or region parameter for each downstream provider. The supported features matrix shows which features are available across regions for each service.

Combining Apple Music with Other Services in One App

The real power of the Apple Music API appears when you combine it with other streaming services. Most music apps today need to work across platforms. Your users might have Apple Music, Spotify, YouTube Music, or Tidal. Some have accounts on multiple services.

Building direct integrations for each service means:

• Separate OAuth flows for each provider (Apple's JWT + Music User Token, Spotify's OAuth 2.0, Google's OAuth with YouTube-specific scopes, Tidal's device code flow)
• Separate response parsers for each provider's data format
• Separate rate limiters for each provider's throttling policy
• Separate error handlers for each provider's error format
• A growing switch statement in every function that touches music data

With a unified API, cross-service features become straightforward. Here is an example that fetches a user's favorite tracks from whatever service they use:

// Works for Apple Music, Spotify, YouTube Music, Tidal, Deezer...
async function getFavoriteTracks(userToken) {
  const response = await fetch(
    'https://api.musicapi.com/me/favorites/tracks',
    {
      headers: {
        'Authorization': `Bearer ${MUSICAPI_KEY}`,
        'X-User-Token': userToken
      }
    }
  );
  return response.json();
}

The response is the same shape regardless of service. Building features like "transfer your playlist from Apple Music to Spotify" becomes a read from one service and a write to another, both through the same API. Check the favorite tracks endpoint and user profile endpoint for the normalized response formats.

MusicAPI handles all the auth complexity, data normalization, and rate limiting across services so you can focus on the features that make your app unique. Get started with unified authentication and connect Apple Music alongside every other supported service.

FAQ

What is the Apple Music API?

The Apple Music API is Apple's REST API for accessing the Apple Music catalog, user libraries, playlists, and recommendations programmatically. It requires a developer token (signed JWT from your Apple Developer account) and a Music User Token for personalized endpoints. The API supports catalog search, playlist CRUD operations, library reads, and personalized recommendations across 175+ storefronts.

How is the Apple Music API different from MusicKit?

MusicKit is Apple's client-side SDK (available as MusicKit JS for web and MusicKit for Swift for Apple platforms). It handles authorization, playback control, and direct API access from the client. The Apple Music API (REST API) is the server-side counterpart: it provides the same data access but works from any backend, any language, any platform. MusicKit includes playback features that the REST API does not. The REST API works cross-platform, which MusicKit does not.

Do I need an Apple Developer account to use the Apple Music API?

Yes. Direct Apple Music API access requires an active Apple Developer Program membership ($99/year). You need the account to generate the private key used for signing developer tokens. If you use a unified API like MusicAPI, the developer token management is handled for you, though you still need users to authorize their Apple Music accounts.

What can I build with the Apple Music API?

Common use cases include: playlist management apps (create, read, update playlists), music discovery tools (catalog search, recommendations), library sync utilities (read user libraries, export track lists), cross-service transfer tools (move playlists between streaming services), and social music apps (share what friends are listening to using library data). The API does not support audio playback, lyrics, or listening history through the REST endpoints.

How do I handle Apple Music API rate limits?

Apple does not publish exact rate limit numbers. Developers typically see throttling at 60 to 120 requests per minute per developer token, though it varies by endpoint. When throttled, Apple returns a 429 status with no Retry-After header, so implement exponential backoff. Batch requests where possible, cache catalog responses aggressively, and avoid polling user endpoints. Using a service like MusicAPI offloads rate limit management entirely: MusicAPI tracks per-provider limits and handles retries transparently.

Can I use the Apple Music API on Android?

Not directly through MusicKit (which is Apple-platform only), but yes through the REST API. The Apple Music API is a standard REST API that works from any HTTP client on any platform, including Android backends. For a simpler approach, MusicAPI's unified endpoints work identically across all platforms and handle Apple Music alongside other services through one integration.

How do I authenticate users for Apple Music API access?

Direct authentication requires two tokens: a developer token (ES256-signed JWT generated server-side with your Apple Developer private key) and a Music User Token (obtained client-side through MusicKit JS or MusicKit for Swift after user authorization). The Music User Token cannot be refreshed; it must be re-obtained when it expires. MusicAPI's auth flow replaces this with a single OAuth redirect and one managed token.

Ready to skip months of OAuth and SDK work? Start your free MusicAPI trial and connect 10+ streaming services with one unified API.