A music API lets an app, a game or a device ask a service for music instead of shipping a fixed folder of audio files. You send a request with a mood, a length and a format. You get back a track, or a stream that keeps playing for as long as you need it.
On paper that is two endpoints and an audio player. In practice the first tester opens the app on a train, the music takes ages to start, the loop clicks every few seconds, and someone from legal asks whether users can export the result. Nobody can answer.
This guide is for developers and product teams who are about to add music to a product. It covers five decisions in the order they usually cause trouble: how the music arrives, how fast it has to start, how it repeats, where the files live, and what users may do with them. The examples use the Mubert API, which generates tracks and streams music for apps, games and services. The questions apply to any provider, though.
Connect the music API in a few minutes
There are three ways in, and the choice depends on who writes the code.
If an AI agent should get music right now, connect the MCP server. In Claude Code that is one command:
claude mcp add --transport http mubert-music https://mcp.mubert.com/mcpClaude Desktop, Cursor and other clients take the same server in their JSON config:
{
"mcpServers": {
"mubert-music": {
"type": "http",
"url": "https://mcp.mubert.com/mcp"
}
}
}On first use the client opens a sign-in page, where you paste the company ID and licence token from the email you got after checkout. The server reads your licence before every request and refuses one your plan cannot fulfil. So an agent does not spend quota on requests that were never going to work.
If you want an agent to write the integration for your own product, install the skill instead. It produces code that calls the REST API:
npx skills add MubertAI/skillsAnd if you write the integration yourself, the REST API is what the rest of this guide is about.
How a music API delivers sound: streams or files
A file is a finished track. You request it, wait for it to be ready, get a link and play it. It works offline and sounds the same every time. It cannot react to anything.
A stream is music that keeps playing until you stop it. That suits a workout that lasts as long as the user does, or a game level nobody can time. But it needs a network connection for the whole session, and every minute counts against your plan.
Our rule of thumb is simple. If the music has to change with what the user does, stream it. If it has to survive a tunnel, a plane or a weak Wi-Fi signal, generate files. Most products need both: a stream while the app is online, plus a saved file for when the connection drops.
This music API does both. REST calls and stream links live on two different hosts, and a stream comes in two flavours, plain http or WebRTC. If you skip the optional settings, a stream starts at bitrate 128, high intensity, over http.
Streams can also change mood without stopping. Intensity has three levels (low, medium and high), which means fewer or more instruments playing at once, and the docs say the switch happens without breaking the stream. So map your game or workout state to those levels. Then add a delay, because music that jumps between calm and intense four times in ten seconds is worse than silence.
How fast the music has to start
Measure music API speed from the moment the user taps, not from the moment your server sends the request. The tap is what people feel.
For streams, the product page lists two options. One buffers about 3 seconds of audio, so playback starts at once. The other is WebRTC, with less than a second of delay, for music that has to answer a button or a game event right away.
For files, the length you ask the music API for matters more than you would expect. A track at 5, 6, 8, 10, 15, 20, 30, 40, 60, 180, 240 or 300 seconds can come from a store of ready-made tracks in one request. Any other length is composed from scratch, so a 30-second intro comes back quickly and a 47-second one takes longer.
So round the length. When your design cannot, request early. A video editor that has to fit music to an exact cut is the classic case: ask for the track when the user opens the timeline, not when they press export, and the wait disappears behind the editing.
Here is a request for a 30-second loop:
curl -X POST "$API_BASE/public/tracks" \
-H "customer-id: CUSTOMER_ID" \
--header "access-token: ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"playlist_index": "PLAYLIST_INDEX",
"duration": 30,
"format": "mp3",
"mode": "loop",
"intensity": "medium"
}'$API_BASE is the REST address from the docs. The playlist index picks a music channel, such as a calm ambient one. You get the full list of channels with one request, and it rarely changes, so cache it on your server.
Make looping music that does not click
Background music in apps and games often repeats. If the end of the track does not join the start cleanly, users hear a small click every time it loops. They notice it by the third repeat, and then they never stop noticing.
The fix starts with the right kind of track from the music API. The docs list four modes. Track mode gives you an intro, a middle and an ending, like a song. Loop mode builds a track to repeat. Jingles are short finished pieces of up to 40 seconds, and mix mode plays tracks one after another, the way a DJ does. Endings do not loop. So use loop mode for anything that repeats.
Playback matters too. MP3 files carry a few milliseconds of silence at the start and the end. Harmless in a podcast. Loud at a loop point. So ask for WAV if your plan includes lossless quality, or trim that silence from the MP3. Then schedule each repeat on the audio clock of your engine, not on a regular timer, because timers drift. In a browser that clock is AudioContext.currentTime; in Unity it is AudioSettings.dspTime.
Streams can loop on the server instead. One call loops the latest part of the music or turns looping off, and it takes the current playback time, so the loop starts where the listener actually is.
Save music API files before the links expire
Every track the music API generates comes with a download link and an expired_at time. How long the link lives depends on your licence: the docs example uses 900 seconds, which is fifteen minutes. So plan for minutes, not days.
The rule that follows: as soon as a track is ready, copy the file to your own storage and serve it from there. Your server can learn that a track is ready in two ways. It can keep asking, or, if your plan includes webhooks, the API can send it a message when the track is done.
Also, store files under the exact settings you asked for (channel, length, mode, intensity, format, bitrate). Then two identical requests reuse one file instead of paying for two generations.
Pick the bitrate per screen. The API offers 32, 96, 128, 192, 256 and 320 kbps, and a phone speaker in a fitness app does not need what a desktop video editor needs.
The docs suggest one more habit that saves money: check what your licence allows, search the ready-made music library, and only then generate something new. You can filter the library by tempo and length, and the product page mentions about 12,000 curated tracks. Not every plan includes the library, so check your licence first.
Set up the music API once on your backend
The music API has two halves. On the company side you manage licences and users with a company ID and a licence token. The user side, which plays music, uses a customer ID and an access token for each end user.
So the licence token stays on your server. It never goes into an app build, a game or device firmware, because anything shipped inside an app can be pulled out of it.
Your server creates a customer when someone signs up and hands the app only that user’s tokens. When an account is deleted, delete the matching customer too. There is a request for exactly that.
Finally, ask the API for your licence when the app starts. The answer lists the features, formats, modes, bitrates and limits of your plan, so the app never shows a button your plan does not support.
Decide what users can do with the music
There are two separate rights here. One is your right to play music inside your product. The other is your users’ right to take it out of the product: export a video, post a reel, publish a podcast episode. We explain how those two layers differ in a separate post. The short version is that the second right does not come free with the first. Read your music API terms for it specifically.
The licence page is clear on two points: distribution or resale of the music is prohibited, and sublicensing is available for user-generated content. On the API page, sub-licensing is not included in every self-serve plan. So if your app has an export button, check your plan, and get the answer in writing before you build that button.
It also helps to know where the audio comes from. The API composes music from samples and loops that real musicians uploaded and get paid for. New to the terms? This beginner’s guide to sublicensing explains them in plain words.
A checklist for your music API integration
- Choose a self-serve plan; credentials arrive by email after checkout.
- Connect through the MCP server, the skill or the REST API.
- Check what your licence allows before you build.
- Search the 12K curated library before you generate.
- Generate by text, image, BPM or genre, from 15 s to 25 min.
- Stream live over WebRTC (sub-second) or buffered (instant start).
- Save every track before its URL expires.
- Sublicense tracks to your users where your plan includes it.
Do these in order and the music will start on time, loop without a click, and still be there tomorrow.
To try it, the API starts with a self-serve plan, and your company credentials arrive by email after checkout. Endpoints are in the docs, plans on the API page.
Who we are
