How Long Does DDEX Delivery Take?

On modern infrastructure, DDEX delivery is nearly immediate. At limbo/, a release that passes quality control is guaranteed delivered to DSPs in under 24 hours. If QC flags something the client needs to fix, the realistic window extends to 48 hours. Anything beyond that is not a delivery problem; it is a content-quality problem. The honest answer to “how long does delivery take” is therefore another question: how good is the release you are delivering?

Here is the whole pipeline, what each step costs in time, and where the delays actually live.

The delivery pipeline, step by step

1. Ingest and quality control. The release (audio, artwork, metadata) enters the platform and gets validated: metadata integrity, ISRC and UPC codes, artwork specs, audio quality, rights and policy checks. This is the step that decides everything downstream.
2. Packaging. The platform generates the DDEX ERN message each DSP expects, in the version each store requires (3.8.2 or 4.3), with the right deals and dates.
3. Transfer. The package moves to each DSP over its ingestion channel. On modern infrastructure this is the fastest step of all.
4. DSP-side ingestion. Each store processes the delivery on its own schedule, with its own validation and review. This is outside any distributor’s control, and it is why lead time matters.
5. Go-live. The release turns on at its release date, market by market.

Steps 2 and 3 are engineering, and engineering is fast. Step 4 belongs to the stores. The variable that separates a smooth release from a stuck one is step 1.

What actually takes the time: content quality

When a release takes days or weeks to reach stores, it is almost never the pipe. It is the release bouncing: artwork at the wrong resolution, a metadata field that contradicts another, a missing ISRC, audio that clips, a contributor credit that trips a rights check. Every bounce means a round-trip to the client, a fix, and a re-validation.

That is why the useful number is not “delivery speed” but first-pass rate: how often a release clears validation the first time. Everything about how a platform is built either pushes that rate up or hides it.

The limbo/ numbers

We can be concrete about our own pipeline:

• Technologically, delivery is close to immediate. Once a release clears QC, packaging and transfer are measured in minutes to hours, not days.
• Under 24 hours, guaranteed. If the metadata, audio and artwork are OK, we guarantee the release is delivered to DSPs in less than 24 hours.
• Up to 48 hours if something needs fixing. When QC flags an issue the client has to correct, the realistic end-to-end window is 48 hours, and most of that time is the fix, not the pipeline.
• Beyond 48 hours means a quality problem. If a release is still not out after that, the content itself has serious quality-control issues, and the right conversation is about the source material, not the delivery.

The reason we can guarantee the first number is Agent Quality Control: every release is validated against Merlin and major-DSP content policies before it enters the delivery queue: metadata integrity, artwork specs, audio QC, fingerprinting, fraud and AI-content checks. Problems get caught at the door, with a human team on top for the judgment calls, instead of surfacing as a DSP rejection a week later.

Delivery is not the same as live

One distinction saves a lot of support tickets: delivered means the store has it; live means listeners can play it. After delivery, each DSP ingests and reviews on its own timetable, and the release activates on its release date. This is why industry practice is to deliver one to four weeks ahead: not because the delivery is slow, but because editorial pitching windows close early and store-side processing deserves slack.

If your current platform quotes you delivery times in weeks, the pipeline is not the problem you should be asking about. Ask about their first-pass QC rate, which DDEX versions they speak per store, and who picks up the phone when a release does get stuck.