Distributing to 50+ DSPs manually with no unified metadata layer?
Revenue reports from each store in a different format that takes days to reconcile?

Music Distribution Software Development

Distributing music to 50 or more DSPs manually -- preparing metadata packages for each store, chasing delivery confirmations, reconciling revenue reports in different formats -- is operational work that scales badly. Every new release adds to the burden. Every new store adds a new format to reconcile.

RaftLabs builds custom digital music distribution platforms that automate DSP delivery, manage metadata at scale, schedule releases with territory controls, and aggregate revenue from every store into one report. Built for labels and distributors who have outgrown manual processes.

DSP delivery pipeline to Spotify, Apple Music, Amazon, and more
Metadata management and ISRC/UPC handling across your full catalog
Release scheduling with territory and date controls per store
Revenue aggregation from all stores into one normalised report

Software products shipped: 100+

Cost delivery: Fixed

Week delivery cycles: 10-14

Industries served: 24+

Distribution software built for the scale and complexity of modern music delivery

Music distribution is a data problem. Each DSP has its own metadata requirements, delivery format, and ingestion timeline. A release that is correctly delivered to Spotify may be rejected by Apple Music because a field is formatted differently. Revenue reports come back weeks later in formats that are incompatible with each other. Reconciling what you earned against what each store claims you earned is manual work that takes days.

A custom distribution platform solves this by creating one standardised internal representation of a release -- the metadata, the audio files, the rights information, the release schedule -- and handling the translation to each DSP's requirements as an automated step. Revenue data comes back from each store and is normalised into one format before it reaches your reporting layer. The operational burden of managing 50 DSP relationships is reduced to reviewing exceptions, not processing every delivery manually.

We build distribution platforms for independent labels, multi-label distributors, and rights management companies. The architecture is designed for your catalog volume, your deal structure, and the number of DSPs you need to reach.

What we build

DSP delivery pipeline

The DSP delivery pipeline connects to all major stores -- Spotify, Apple Music, Amazon Music, TIDAL, YouTube Music -- via their preferred ingestion methods, plus aggregator partnerships via TuneCore, DistroKid, or CD Baby APIs for stores that don't offer direct distributor access. For stores that accept direct delivery, the pipeline uses the DDEX ERN (Electronic Release Notification) standard: ERN 3.8 and ERN 4.1 are the current versions in active use, and the pipeline is configured per store based on what each store's ingestion system accepts.

Each release is packaged with the audio files (WAV 16-bit/44.1kHz or 24-bit/48kHz as required by the store), the metadata XML built from your internal release record, and the cover art at the required minimum resolution (typically 3000x3000 pixels, RGB, JPEG). The package is delivered via SFTP to stores that use batch ingestion, or via REST API for stores like Apple Music and Amazon that have transactional delivery endpoints.

Delivery status is tracked per store in a real-time dashboard -- submitted, processing, confirmed, live, or rejected -- so your operations team knows where each release stands across all 50-plus stores without logging into each store's portal. Failed deliveries surface the specific rejection reason from the store's error response (missing ISRC, incorrect genre taxonomy, audio file below minimum bitrate) so corrections can be made and the release redelivered quickly. The pipeline architecture uses a plugin model for store integrations, so adding a new DSP requires building a new delivery adapter rather than modifying the core pipeline.

Music metadata management

Metadata management stores track and release data in a normalised internal schema based on the DDEX RIN (Recording Information Notification) and ERN standards, which provides a consistent internal representation regardless of what any individual DSP requires. ISRC (International Standard Recording Code) registration is handled within the platform: ISRCs are assigned per recording using your ISRC registrant prefix, tracked against each sound recording, and included in every delivery package. If you have existing ISRCs from a previous distributor, they are imported via CSV during onboarding and linked to their recordings.

UPC barcodes are assigned per release and managed in the platform's release registry. The UPC is embedded in every DDEX package delivered to stores. Metadata fields that differ between stores -- genre taxonomies (Spotify and Apple Music use different genre trees), parental advisory formats (explicit flag, clean flag, or store-specific rating strings), contributor credit structures (producer, mixing engineer, featuring artist credit formats) -- are mapped automatically at delivery time using store-specific transformation rules, so the operator enters metadata once in the normalised internal format.

Metadata schema per DSP is maintained as a configuration layer: when a store updates its ingestion requirements, only the store's transformation rule needs updating, not the underlying release data. Metadata corrections made in the platform propagate to stores that accept update deliveries without requiring a full takedown and redelivery cycle. The DDEX RIN standard is also used for metadata exchange with Harry Fox, Music Reports, and SoundExchange registrations, so a single metadata record serves both DSP delivery and royalty collection society registrations.

Release scheduling and territory control

Release scheduling allows the operator to set a release date globally or per territory, with embargo controls so a release goes live at local midnight in each territory's time zone (or at a single global UTC time for simultaneous global releases). Territory-based rights management is handled at the release level: rights can be restricted to specific territories (Spotify North America and Europe only, for example), excluded from specific stores in specific markets, or set to worldwide. Territory configurations are enforced in the DDEX package's rights section, so each store's ingestion system receives the correct territorial availability for the release.

Pre-save links for Spotify and pre-order links for Apple Music and Amazon Music are generated automatically when a release is scheduled, so the artist can begin promotion before the release date. Pre-add for Apple Music is also supported. Territory exclusions and store exclusions are configured per release in the scheduling interface without requiring a separate metadata edit.

Schedule changes made after submission trigger an amendment delivery to stores that accept amendment packages (DDEX update notifications) and a takedown-and-redeliver cycle for stores that require a fresh delivery. The platform tracks whether each change requires an amendment or a full redeliver and handles the correct workflow automatically. Takedown management -- removing a release from all stores or from specific stores -- is initiated from the platform and tracked to completion per store, including the confirmation that the release has been delisted.

Revenue reporting aggregation

DSP revenue statements arrive in incompatible formats: Spotify delivers CSV via the Spotify for Artists reporting API, Apple Music delivers through Apple Music for Artists reports, Amazon Music uses their own CSV format, and smaller stores often deliver Excel files via email or FTP. Some stores report monthly, others weekly. Some report in USD, others in local currency. Reconciling this data manually takes days per reporting cycle.

The revenue aggregation layer ingests each store's statement format via its native delivery method -- API pull for stores that have reporting APIs (Spotify, Apple Music, Amazon Music, TIDAL), CSV and EDI parsing for stores that deliver structured files, and email attachment parsing for stores that send statements via email. Each statement is parsed into the platform's normalised revenue schema: store, period, ISRC, UPC, territory, stream count, download count, revenue amount, currency.

Currency conversion applies the ECB reference rate or the store's stated conversion rate to normalise all revenue to your base reporting currency. Streaming rate per-play is calculated from the revenue and stream count per store per period, giving your team visibility into effective per-stream rates by store and territory over time. Publisher split accounting with co-writer percentage tracking applies the split percentages from each track's split sheet to the normalised revenue, calculating each rights holder's earned amount before disbursement. Harry Fox and Music Reports mechanical royalty reconciliation compares platform-calculated mechanicals against statements received, flagging discrepancies for review. SoundExchange digital performance royalty data is ingested alongside DSP revenue so featured artist and sound recording copyright owner royalties are tracked in one system.

Label and artist dashboard

Label dashboards surface release status across the full roster: which releases are delivered and live, which are pending confirmation at specific stores, which have failed deliveries requiring attention, and the release schedule for the next 30 and 90 days. Revenue performance is visible at the label level (total earnings by period, by store, by territory), at the release level (streams, downloads, and revenue per release), and at the track level (ISRC-level data showing which tracks are driving the most activity). Delivery confirmations from each store are surfaced in the dashboard as they arrive so the operations team does not need to poll each store's portal.

Artist dashboards show each artist their own releases, their streaming numbers by territory and by store, their revenue statements per period, and their ISRC and UPC registrations. Access is strictly role-based: a label account sees the full roster, a sub-label account sees only their own catalog within the parent distributor's structure, and an artist account sees only their own releases. This role-based access control (RBAC) model is enforced at the API level, not just at the UI level, so an artist cannot retrieve data belonging to another artist even by making direct API calls.

Release management workflows within the dashboard cover the complete release lifecycle: metadata entry, audio file upload, territory and store configuration, release scheduling, delivery submission, live monitoring, and takedown. The dashboard is the single interface for release management from submission to live -- the operations team does not need to log into individual store portals for routine operations.

Content ID and rights registration

YouTube Content ID integration registers your sound recordings with YouTube's Content ID system so that user-uploaded videos that contain your music are identified and monetised or blocked on the day of release rather than weeks later. The Content ID reference file (the audio recording) and the ownership policy (monetise, track, or block, per territory) are submitted from the same metadata record used for DSP delivery -- ISRC, rights holder splits, and territory availability flow automatically without a separate data entry step.

Rights registration data is submitted to SoundExchange for digital performance royalties (paid to featured artists and sound recording copyright owners for non-interactive streaming on services like Pandora and SiriusXM), to Harry Fox Agency (HFA) or Music Reports for mechanical royalty licensing (paid to publishers and songwriters for on-demand streaming and downloads), and to your PRO (ASCAP, BMI, SESAC, PRS, SOCAN) for performance royalties where applicable. Co-writer percentage tracking and publisher split accounting ensure that mechanical royalties calculated from DSP streaming data are allocated to each rights holder at their contractual percentage before disbursement.

Content ID claim reports are pulled from YouTube via the YouTube Reporting API and normalised through the same revenue aggregation layer as DSP statements, so YouTube Content ID earnings are visible in the same revenue dashboard as Spotify and Apple Music streaming revenue. SoundExchange statements are ingested and reconciled against the platform's own performance data to flag discrepancies. The rights registration layer ensures your catalog is properly claimed and monetised across all revenue streams from the day each release goes live.

Frequently asked questions

: Each DSP has its own ingestion method and required format. Spotify, Apple Music, and Amazon Music use DDEX ERN (Electronic Release Notification) as their preferred metadata format -- DDEX ERN 3.8 is the most widely accepted version, with ERN 4.1 required by some stores. DDEX is an XML schema standard developed by the Digital Data Exchange consortium specifically for music metadata and asset delivery, and it is what all major stores expect when a label or distributor delivers directly.
The delivery pipeline works as follows: the release record from your internal metadata store is transformed into a DDEX ERN XML package for each target store, combined with the audio files and cover art, and delivered to the store's ingestion endpoint. Stores that use SFTP batch ingestion (common for smaller DSPs) receive a ZIP package dropped to their SFTP server. Stores that have REST API endpoints (Apple Music, Amazon Music) receive the package via an API call with the DDEX XML as the payload and the audio/artwork files as multipart attachments.
After delivery, the pipeline polls the store's status endpoint (or waits for a status webhook if the store supports it) to track whether the package has been received, is being processed, is live, or has been rejected. Rejection responses include a machine-readable error code and a human-readable error message -- typical rejection reasons include missing or invalid ISRC, audio file below the store's minimum bitrate requirement, cover art dimensions below the minimum, or genre values that don't match the store's taxonomy. The delivery tracking layer surfaces these exceptions to your operations team in the dashboard so corrections can be made and the release redelivered without the operator needing to log into the store's portal to diagnose the failure.
: All three are supported as first-class data in the platform. ISRC (International Standard Recording Code) is a 12-character identifier assigned to each unique sound recording -- the same recording distributed to multiple stores carries the same ISRC, which is the mechanism that allows royalty collection societies and Content ID systems to match plays and uses back to the correct rights holder. ISRCs are registered through national agencies (RIAA in the US, BPI in the UK), and if you have an ISRC registrant prefix, the platform handles ISRC assignment and tracks each code against its recording. If you don't have a registrant prefix, the platform supports assignment through a third-party ISRC issuer.
UPC (Universal Product Code) is the 12 or 13-digit barcode assigned to each release -- a single-track single and a 12-track album each get their own UPC. The platform assigns and tracks UPCs from your registered GS1 prefix, or through a third-party barcode issuer for labels that don't have their own prefix.
DDEX (Digital Data Exchange) is the XML schema standard used for metadata delivery. The platform supports DDEX RIN (Recording Information Notification) for internal metadata management and DDEX ERN (Electronic Release Notification) versions 3.8 and 4.1 for delivery packages. The specific ERN version used for each store is configured in the store's delivery adapter based on what that store's ingestion system accepts. DDEX MWN (Musical Work Notification) is also supported for publishing-side metadata delivery to Harry Fox and Music Reports for mechanical licensing.
: Multi-label architecture is built into the platform's data model as a standard requirement for distributors. The hierarchy supports a parent distributor account with multiple label accounts beneath it, and optional sub-label accounts beneath each label. Each level has its own catalog, its own artist roster, its own release schedule, and its own revenue reporting. User accounts are scoped to a specific level of the hierarchy: a label administrator sees their own label's data; a sub-label user sees only their sub-label's catalog; the parent distributor administrator sees everything.
Revenue and royalty reporting is generated at any level of the hierarchy: a sub-label sees their own earnings, a label sees total earnings across all their sub-labels and direct signings, and the parent distributor sees total earnings across all labels. Royalty split accounting between the distributor and each label is applied at the reporting stage based on your configured deal terms per label -- a label on a 70/30 split sees their 70% in their label-level report, and the parent distributor sees the 30% distributor fee accumulated across all labels.
ISRC and UPC management is also hierarchical: codes are assigned from the appropriate registrant prefix at the label level. If labels have their own registrant prefixes, the platform supports multiple prefix pools managed per label. Delivery workflows are owned by the level that has the relevant store relationship -- the parent distributor may have direct deals with Spotify and Apple Music, while a sub-label may distribute to a smaller set of stores via an aggregator. Both delivery paths are supported within the same platform instance.
: A focused distribution dashboard -- DDEX ERN delivery pipeline to the major stores (Spotify, Apple Music, Amazon Music, TIDAL, YouTube Music), ISRC and UPC management, metadata management, and revenue aggregation from DSP CSV and API statements into one normalised report -- typically costs $20,000 to $50,000 and delivers in 10 to 14 weeks. This covers the core distribution and reporting workflow for a label or small distributor that currently manages these processes manually.
A full distribution platform with multi-label hierarchy and RBAC, territory and store scheduling controls, TuneCore/DistroKid aggregator integration for stores without direct delivery APIs, YouTube Content ID integration, SoundExchange and Harry Fox mechanical royalty ingestion, publisher split accounting with co-writer percentage tracking, a label administrator dashboard, and an artist-facing portal with per-release streaming and revenue data typically costs $40,000 to $100,000. The range reflects variation in the number of DSP delivery integrations (each direct store integration adds cost), the complexity of the royalty accounting model (flat splits are simpler than tiered or recoupable deal structures), and whether the revenue aggregation needs to handle EDI statements in addition to CSV.
The largest cost variable is the number of DSP integrations required from day one. Each direct store integration (distinct from aggregator-based delivery) requires building and testing against that store's specific DDEX variant, SFTP or API delivery method, and status response format. We scope the integration list and the royalty accounting model before committing to a fixed price.

What clients say

What our clients say

Three-year average engagement. Founders and operators describing the work in their own words. No marketing varnish.

Dr. J. Ayo Akinyele

USA

President, Co-Founder

I was pleased with RaftLabs team quality, consistency and execution.

01 / 02

Case studies

Boost in brand sales after launch25%

More user engagement2x

From idea to launch16 weeks

Sponzee Connects Brands and Creators in a Social Commerce Revolution

Related services

Custom Software Development -- Custom music streaming platforms, distribution pipelines, royalty management systems, and artist tools
AI Agent Development -- Autonomous agents for rights detection, royalty anomaly flagging, and content recommendation
Business Process Automation -- Automate DSP delivery workflows, royalty ingestion, split sheet processing, and payment disbursement

Talk to us about your music distribution platform.

Tell us how many DSPs you are delivering to, where the manual work is piling up, and what your catalog volume looks like. We will scope a distribution platform built around your operation.