DDEX feed generation is the process of turning a music release and its metadata into a standardized XML message that streaming platforms can ingest automatically. The format is DDEX’s ERN (Electronic Release Notification), and it carries everything a DSP needs to publish a release: titles and artists, ISRCs, references to the artwork and audio files, plus the territories and deal terms that apply. Generating that feed correctly is what gets your music delivered without manual re-entry.
This guide explains what an ERN message contains, how feed generation works step by step, the difference between ERN 3.8.2 and 4.3, and how to evaluate a provider that handles it for you, including where LabelGrid fits.
What is DDEX and why does it matter for distribution?
DDEX (Digital Data Exchange) is the not-for-profit standards body, formed in 2006, that defines the XML message formats used across the digital music supply chain. Labels, distributors, DSPs, publishers and collection societies use them to exchange release, rights and sales data automatically, instead of building a custom integration for every partner (About DDEX). For distribution, the standard that matters is ERN (Electronic Release Notification): the message that carries a new release, references to its audio and artwork, and its deal terms to a DSP.
LabelGrid delivers releases to DSPs as DDEX ERN messages and supports ERN 3.8.2, 4.3.0, 4.3.1 and 4.3.2. LabelGrid is not a DDEX member, and membership is not required to implement the standards: anyone can do so under DDEX’s free Implementation Licence (DDEX standards). The hard part, and the one most labels would rather not own, is generating valid ERN feeds and keeping them current as each DSP’s requirements change.
What is a DDEX ERN feed?
An ERN feed is an XML document that describes one release and how it should be made available. The core message is the NewReleaseMessage, and it bundles three things a DSP needs together: the assets, the release, and the terms.
- ResourceList holds the sound recordings plus any video or images, each with identifiers (ISRC for tracks) and technical details.
- ReleaseList is the release itself: title, display artist, label name, UPC, genre, release date.
- DealList sets the commercial terms, including which territories and platforms get it, release timing, and any pre-order window.
Record companies and distributors send these messages to DSPs; the DSP parses the feed and publishes the release according to the deal terms (DDEX ERN documentation). A takedown, a metadata correction, or a new territory each becomes its own message in the same format. A schema violation or a missing required field gets the delivery rejected, which is why validation matters as much as generation.
How does DDEX feed generation work?
Feed generation takes your release data and produces a DSP-ready ERN package. A typical pipeline runs like this:
- Collect the metadata. Release and track fields, contributors, identifiers (ISRC, UPC), territories, and explicit advisories.
- Reference the assets. Audio files transcoded to each DSP’s spec and artwork meeting size requirements (typically a 3000x3000px square master) are attached as resources.
- Validate. The feed is checked against DDEX schema and the target DSP’s own profile before anything is sent. Missing copyright lines, malformed ISRCs, or undersized art are caught here.
- Generate the ERN XML. The
NewReleaseMessageis built with the right version (3.8.2 or 4.3) for the destination. - Deliver. The package is pushed to each DSP and an acknowledgment is returned.
- Handle updates. Corrections, takedowns, and new-territory adds are sent as follow-up messages keyed to the same release.
The reason this is non-trivial: roughly 99,000 new tracks were delivered to streaming services every day in 2024 (Luminate 2024 Year-End Report). Nobody hand-codes XML at that volume. LabelGrid handles DDEX feed generation end to end, generating and validating ERN against each DSP’s current profile and delivering to all major platforms, so labels and distributors send releases rather than build and maintain a feed engine.
ERN 3.8.2 vs ERN 4.3: which version do DSPs use?
Two ERN generations are still in use. ERN 3.8.2 lives on in existing DSP integrations, even though DDEX stopped supporting every ERN 3 version on 1 March 2025. ERN 4.3.x is the current generation, and DDEX advises implementing its most recent version. They are not interchangeable. A feed engine has to speak whichever version each DSP expects.
| Aspect | ERN 3.8.2 | ERN 4.3.x |
|---|---|---|
| Status | Legacy; DDEX support ended on 1 March 2025 | Current; DDEX advises implementing the latest version |
| Territory data | DetailsByTerritory blocks repeat titles per territory | Territorial overrides only where data actually differs |
| Contributors | Artists and writers repeated throughout the message | Defined once in PartyList, referenced by ID |
| Track releases | Full release structure, with redundant fields | Lightweight TrackRelease composite |
| Message size | Larger, due to duplication | Smaller, deduplicated |
| Spatial audio | Limited immersive-audio support | Full immersive-audio support, added in 4.3 |
The practical takeaway: existing ERN 3 integrations persist because moving from ERN 3 to 4 means restructuring the whole territorial data model, since ERN 4 drops the DetailsByTerritory blocks. Newer capabilities, including full immersive-audio support and PartyList deduplication, need ERN 4. A provider worth using supports both and picks the right one per destination. LabelGrid delivers in DDEX ERN 3.8.2, 4.3.0, 4.3.1 and 4.3.2. DDEX import, which brings your own ERN deliveries into LabelGrid, is available on API plans and Custom Distribution.
The stakes for getting delivery right keep climbing. Streaming reached 69.6% of global recorded music revenue in 2025, with 837 million paid subscribers (IFPI Global Music Report 2026). A rejected or malformed feed is lost visibility on the channel where most of the money now is.
Skip the ERN engineering
LabelGrid generates valid ERN 3.8.2 and 4.3 feeds and keeps them current as DSP requirements change.
See PlansWhat should you look for in a DDEX feed generation service?
If you’re choosing a provider to generate feeds rather than building your own, this is the checklist that matters.
| Criterion | What good looks like |
|---|---|
| Multiple ERN versions | Both 3.8.2 and 4.3.x, selected per DSP, not one-size-fits-all. |
| Pre-delivery validation | Schema and per-DSP profile checks that catch errors before delivery, not after rejection. |
| Spec maintenance | The provider tracks DSP profile changes so your feeds don’t silently break. |
| Audio transcoding | Files encoded to each platform’s spec as part of the pipeline. |
| Takedowns and updates | Corrections, territory changes, and takedowns handled as proper follow-up messages. |
| API access | Programmatic delivery and status, so feed generation can run inside your own systems. |
| SOBO support | Ability to deliver under your own DSP contracts if you hold direct deals. |
How to deliver music via DDEX: a step-by-step path
- Decide build vs buy. Maintaining an ERN engine and tracking every DSP profile change is real ongoing engineering. For most labels and distributors, using a provider is the rational call.
- Confirm version coverage. Make sure the provider generates both ERN 3.8.2 and 4.3.x and routes the right version to each DSP.
- Prepare clean metadata. Accurate ISRCs and UPCs, correct copyright lines, and artwork at spec. Clean input is what passes validation.
- Validate before delivery. Run the feed through schema and per-DSP checks. Fix what’s flagged before anything ships.
- Deliver and confirm. Push to each DSP and watch for acknowledgments. Track which platforms have accepted the release.
- Maintain the catalog. Send corrections, new territories, and takedowns as follow-up messages, and keep an eye on feeds when DSP specs change.
LabelGrid fits this path with full DDEX feed generation across ERN 3.8.2, 4.3.0, 4.3.1, and 4.3.2, pre-delivery validation, audio transcoding, and delivery to all major DSPs. For teams that want to run it programmatically, the same pipeline is available through LabelGrid’s REST API with a sandbox and public docs. LabelGrid is a Spotify Preferred Provider and a Merlin Network member. It keeps feeds current as platform requirements change.
DDEX feed generation: the bottom line
DDEX feed generation converts a release into a standardized ERN message, the NewReleaseMessage carrying resources, release data, and deal terms, that DSPs ingest automatically. The two versions still in use are ERN 3.8.2 (legacy; DDEX support ended in March 2025) and 4.3.x (current, smaller, with full immersive-audio support), and a good provider speaks both, validates before delivery, and tracks DSP spec changes. Building your own engine is a continuous maintenance burden; for almost everyone, a provider that takes the feed from generation through validation to delivery is the better choice. LabelGrid handles DDEX delivery for labels and distributors across all four supported ERN versions, with API access and SOBO for direct-deal catalogs.
Frequently Asked Questions
What is a DDEX feed?
A DDEX feed is a standardized XML message, usually an ERN NewReleaseMessage, that describes a music release and how DSPs should make it available. It carries the audio and image resources, the release metadata, and the deal terms (territories, timing, platforms) in one package the DSP can ingest automatically.
What is the difference between ERN 3.8.2 and ERN 4.3?
ERN 3.8.2 is a legacy version: DDEX stopped supporting it on 1 March 2025, but some DSP integrations still use it. It repeats data like titles across territory blocks. ERN 4.3.x is the current version DDEX advises implementing: it deduplicates contributors into a PartyList, only sends territorial data where it differs, adds a lightweight TrackRelease composite, and has full support for spatial audio like Dolby Atmos. LabelGrid supports both.
Do I need to generate DDEX feeds myself?
No. Most labels and distributors do not need to: a provider can generate and validate ERN feeds and deliver them to DSPs. Building your own engine means writing valid ERN XML, validating against each DSP’s profile, and tracking every spec change over time. That is continuous engineering that only pays off at major scale.
Is LabelGrid a member of DDEX?
No. LabelGrid is not a DDEX consortium member, and DDEX membership is not required to implement the standard. LabelGrid implements DDEX ERN and supports versions 3.8.2, 4.3.0, 4.3.1 and 4.3.2 for delivery. DDEX import is available on API plans and Custom Distribution.
What is SOBO in DDEX delivery?
SOBO stands for “sent on behalf of.” It is a DDEX directive specifying that the licensor of a release is the customer, not the distributor. It lets a label or distributor that holds its own direct DSP contracts deliver through a platform like LabelGrid while keeping the direct relationship and royalty terms intact.
Which ERN version should a new catalog use?
DDEX advises implementing the most recent version, ERN 4.3.x. It is smaller and deduplicated, with full support for spatial audio and richer credits. Some DSP integrations still run on ERN 3.8.2, so a good provider routes the correct version per destination. LabelGrid handles that automatically across all four supported versions.
