Your library transfer cost is one multiplication: billable requests times the rate of the bucket they land in. MusicAPI meters one thing, the requests it makes to music streaming services on your behalf. The rate card models a typical listener at about 2,000 songs: roughly 60 source requests to read that library, plus about 120 destination requests when MusicAPI writes the destination too. At the entry rate of €0.60 per 1,000 requests, one completed import costs €0.036 when you own the destination, and €0.108 when MusicAPI runs both sides.
Everything after that is multipliers. This post builds the model up from the request: what counts, which architecture halves the meter, how repeat syncs and resumed runs stack, how a 200,000 item library pages differently from a 40 playlist import, and where the curve bends at the 5M and 25M monthly thresholds. It prices the feature after it ships. If you are still deciding whether to write it, the playlist transfer build vs buy model prices engineering weeks and ownership instead.
What counts as a billable request
One request is one HTTP call from MusicAPI out to a music streaming service. Reading a page of playlists, fetching a track, creating a playlist entry: each one is a unit. Calls your own backend makes into the MusicAPI API are a different set, and only the outbound calls are counted.
Four things that are not on the meter, and that keep showing up in spreadsheets anyway:
- Authentication redirects, dashboard seats, webhooks, sandbox traffic and support.
- Per-seat and per-user fees. There are none.
- Transfers that fail to match, as a category.
- Provider errors that MusicAPI retries.
One nuance sits inside that list. A read that went looking for a match and found nothing still counts, because the call went out. So the search side costs the same whether most items match or few do: the read that found no match still counts. Match quality belongs in your churn model, not in your invoice. If that is the number you are chasing, playlist transfer accuracy is the scorecard, not this page.
The split that decides architecture, not just budget
The meter follows who talks to the destination service. On MusicAPI Core your backend writes into your own platform, so only the requests sent to the source service are metered. On MusicAPI Managed Transfers the hosted flow runs both halves, so source reads and destination writes both count. The practical guidance on the rate card is to budget around twice the request volume for the same transfer on Managed Transfers.
| Dimension | MusicAPI Core | MusicAPI Managed Transfers |
|---|---|---|
| Metered side | Source reads only | Source reads and destination writes |
| Requests per typical transfer | About 60 | About 180 |
| Who writes the destination | Your backend, on your infrastructure | MusicAPI, through the hosted flow |
| Monthly minimum | Own developer credentials: you pay the meter | Managed credentials: at least €500 a month |
| Cost per import at €0.60 per 1,000 | €0.036 | €0.108 |
| Cost per import at €0.30 per 1,000 | €0.018 | €0.054 |
Read the minimum row carefully, because it follows the credentials rather than the product. The €500 floor applies when you run on MusicAPI managed credentials, and the bill is the greater of your metered usage and €500. At the entry rate, €500 buys about 833,000 requests, which is roughly 4,600 completed imports at 180 requests each. Below that volume on managed credentials you are paying the floor, not the meter.
That is the real decision. Managed Transfers costs about twice the metered volume and removes the wizard, the matching and the retry logic from your roadmap. Per-provider OAuth clients and token refresh, normalized playlist and track shapes, ISRC matching with a fuzzy fallback, per-service 429 handling and paging a large library are the work it takes off you. The mechanics are in how Managed Transfers works.
The base unit, checked against the paging arithmetic
The 60 source request figure is a planning assumption for a 2,000 song library, covering paged reads of playlists, albums, likes and track metadata. It survives a sanity check. A 40 playlist import where each playlist holds 50 tracks is 2,000 items, and Spotify returns playlist items at a maximum of 50 per page. That is 40 item pages plus the playlist list and a little metadata, which lands in the same neighbourhood as the documented 60.
Page size is the lever. MusicAPI exposes limitParam, adjusted to the limitations of each music service, and the per service cap is published in the services table: the highest limitParam the service takes, with anything larger cut down to it. YouTube accepts maxResults between 0 and 50. Cursor paging then walks the rest, passing the nextParam from the previous response. Fewer items per page means more requests for the same library, so the same user costs more on a service with a small page cap. The music API pagination guide covers the mechanics.
Cost per activated user
Define an activated user as one completed import. The Core column assumes your own developer credentials and 60 metered requests per import; the Managed column assumes MusicAPI managed credentials and 180. Bills are cumulative within a calendar month: the first five million requests at the top rate, the next twenty million at the middle rate, everything beyond at the floor.
| Imports per month | Core requests | Core bill | Core per import | Managed requests | Managed bill | Managed per import |
|---|---|---|---|---|---|---|
| 2,000 | 120,000 | €72 | €0.036 | 360,000 | €500 (floor) | €0.250 |
| 5,000 | 300,000 | €180 | €0.036 | 900,000 | €540 | €0.108 |
| 25,000 | 1.5M | €900 | €0.036 | 4.5M | €2,700 | €0.108 |
| 100,000 | 6M | €3,450 | €0.035 | 18M | €8,850 | €0.089 |
| 500,000 | 30M | €13,500 | €0.027 | 90M | €31,500 | €0.063 |
Two things fall out of the table. First, the floor dominates at low volume on managed credentials: 2,000 imports a month cost the same as 4,600 would. If you are piloting, the per user number you quote internally is the floor divided by real imports, not the meter. Second, the per import cost barely moves until you cross five million requests, then drifts down slowly. Nobody grows into a materially cheaper unit cost by accident.
What multiplies the base number
The 60 and 180 figures describe one clean run for one listener. Four things stack on top.
Repeat syncs. A one time onboarding import is one read of the source. A weekly refresh is 52 of them a year, per user, and each one pays source request cost again. Sync products should model requests per user per month, not per user.
Wizard refreshes. When a user connects an account, MusicAPI reads the library once and keeps a snapshot, and every wizard screen reads that snapshot rather than the service. Picking content is therefore free of extra calls. A Refresh in the wizard reads the library again, which is a second full read. If your copy nudges users to refresh, you are paying for it.
Reauth and resumed runs. A transfer can land in waitingForReauth, and it continues after the user signs in again or your backend pushes a new token. Nothing is lost there. On Core the same situation is a 412 with internalCode 14, and whether your resume logic re-reads pages it already fetched is your design decision and your line item. Checkpoint by cursor, not by user.
Content breadth. Playlists, followed playlists, liked tracks, albums and artists are each content the wizard can move from the source, and the source budget covers paged reads of playlists, albums, likes and track metadata. An import that offers everything costs more per user than one that offers playlists only, and it converts differently. That trade is covered in music library import UX.
A 200,000 item library is a different product
Scale the paging, not the user. At 50 items per page, a 200,000 item library is at least 4,000 page reads on the source before albums, artists and likes are counted. At the entry rate that is roughly €2.40 of source requests for one listener, which is the whole metered cost on Core, because writes into your own catalogue happen on your infrastructure.
The destination side behaves differently. The rate card describes it as one request to match each song and one to add it. Taken per item, 200,000 items models at 400,000 destination requests, about €240 at the entry rate and about €120 if those requests land in the floor bucket. For typical libraries the 120 request figure is the right budgeting number. For a product whose users carry six figure libraries, price the destination side per item and get the ratio confirmed before you sign anything; committed volume above 25M requests a month is priced by sales, as the MusicAPI pricing rate card says.
Two budgets, not one
Euros are the first budget. Your own request rate is the second, and they count different calls. The meter counts calls MusicAPI sends outward to streaming services. The rate limit counts calls you send inward: each partner account has one limit for all its keys and credentials together, 300 requests per minute by default, with hosted sign-in pages and webhooks excluded. Over it, the API answers 429 with Retry-After: 60. The limit can be raised or removed on request.
That ceiling shapes schedule, not spend. Transfers for one person run one after the other, never side by side, and when a service asks MusicAPI to slow down the transfer waits and continues by itself. If you are sizing how long a backfill takes rather than what it costs, playlist transfer time does that arithmetic, and the rate limits and errors doc has the retry shape.
A third budget exists on your own developer credentials: provider quota. A YouTube playlistItems.list call costs 1 quota unit, and that unit is spent whether or not the euro meter moves.
What goes in the model
Six inputs, and no more:
- Completed imports per month.
- Requests per import, split into source and destination.
- Average items per library, because the destination side scales with items.
- Sync frequency per user, if the feature is not one time.
- Which credentials you run on, which sets whether the €500 floor applies.
- The month you expect to cross 5M requests, which is about 83,000 Core imports or about 28,000 Managed imports at the documented ratios.
Skip months of OAuth and per-provider SDK work. Sandbox keys are free and instant, and one API moves libraries between the supported streaming services. Put your own numbers against the buckets on the MusicAPI pricing rate card before next year's budget is locked.
FAQ
Does sandbox usage cost anything?
No. Sandbox requests are not metered, and the €500 minimum starts on the first production call. Every account starts in evaluation with 5 connected users.
Do unused requests roll over?
No. Buckets are cumulative within a calendar month, and an unused month does not credit the next one.
Can we ship on Managed Transfers and move heavy flows to Core later?
Yes. Many customers ship the hosted flow to get live, then move high volume flows onto Core, and both feed one meter and one invoice.
Are there penalties for going over the top bucket?
No. Rates only step down as buckets fill, and there is no cap on volume in the third bucket. Above 25M requests a month, a committed volume contract with a custom floor rate is priced by sales.