Delivery & Takedown

These two endpoints submit a release for distribution to stores or request its removal. The other Supply Chain endpoints— pricing tiers, monetization policies, and territories clearances—configure what is sent to each destination.

Both endpoints accept a list of distributorStoreIds and return a boolean. Store IDs come from the V1.0 API.

V1.0 Retail Save

POST /content/release/retail/save is still required for fields that do not have V2.0 equivalents, currently the sale start date and preorder date.

When calling this endpoint, keep the request body minimal: include only the properties you need to set through V1.0. Do not send a full release payload, because values that are already managed through V2.0 can be overwritten by the V1.0 request.

A sale start date in the past can also cause delivery validation to fail.

Inspection

A successful Deliver request does not publish a release immediately. It submits the release to the organization inspection queue. An inspector from your organization must review and approve the release in the Revelator UI before it proceeds through the distribution pipeline.

Some releases may additionally require a Deal Owner Inspection after organization approval. Whether this applies is determined by your agreement with Revelator rather than by anything in the request; when it does, the release moves through the -19 to -21 statuses in Distribution Status Lifecycle. The conditions and review process are described in How to pass the final inspection review for Revelator deals.

There is no public API endpoint for either inspection approval.

inspectionStatus also affects how much of the release you can edit—see Lock Levels.

Validate First

Deliver and Takedown run validation before changing the distribution state. Their corresponding validate endpoints run the same rules without side effects—see Validations.

• For Deliver, call GET /supply-chain/v1/releases/{releaseId}/deliver/validate first.
• For Takedown, call GET /supply-chain/v1/releases/{releaseId}/takedown/validate first.

Every finding carries a severity. Only error blocks the operation; a warning never does, and a release can be delivered or taken down with warnings present. You do not need to interpret the findings yourself to know whether the call will succeed: the response’s hasBlockingErrors flag is the same check the Deliver and Takedown calls apply, so false means the operation will not be rejected by validation.

Validation is all-or-nothing across the request. A single blocking error on a single store rejects the entire request—no store is delivered or taken down. The rejection does not identify which store caused it, so submit only stores you have already confirmed are ready.

Store Availability

Deliver and Takedown also require that every requested store is available to your organization. Before building distributorStoreIds, call the V1.0 store lookup with activeOnly=true, which restricts the response to stores that are currently active:

GET /common/lookup/stores?activeOnly=true

From that response, use only entries where both isActive and display are true. An entry missing either flag is not available to your organization, and including it causes Deliver or Takedown to fail with the same generic error, without naming the store.

YouTube Content ID

One additional Deliver rule applies to YouTube: YouTube Content ID (307) cannot be delivered without YouTube Music (13). A Deliver request that includes Content ID must include YouTube Music as well. The reverse does not apply—YouTube Music can be delivered on its own.

The territory rules for the two must also stay consistent; see YouTube Rights Consistency. Validate Delivery reports this relationship when it is not satisfied.

What the Response Means

Both endpoints return a boolean indicating that the request was accepted. The response does not mean that distribution or takedown has completed.

The distribution pipeline continues asynchronously after the request is accepted. The release’s hasDistribution, inspectionStatus, and isProcessing fields on GET /catalog/v1/releases/{releaseId} may therefore not reflect the new state immediately.

For the actual per-store status there is no V2.0 endpoint yet. Read it from the V1.0 API:

• GET /distribution/store/all?releaseId={releaseId} — one entry per store for a single release.
• GET /distribution/release/all — distribution status across releases.

Each entry carries a releaseStatus object containing a numeric status and a human-readable statusText:

{
	"distributorStoreId": 1,
	"releaseStatus": {
		"status": -10,
		"statusText": "In inspection",
		"deliveryDate": "2026-05-01T15:04:58.793",
		"dateLive": null,
		"urlInStore": null
	}
}

Distribution Status Lifecycle

Each release-and-store pair has its own distribution status. Deliver and Takedown each set an entry point into this lifecycle; the intermediate states are driven by the distribution pipeline.

The 0–46 range contains additional intermediate and failure states. For the complete enumeration, see the V1.0 distribution documentation.

A store is eligible for takedown only once the release is live and settled there—not while it is still in inspection, still moving through the pipeline, or already in a takedown flow. See Takedown Eligibility.

Some distribution states also affect whether a release can be archived—see Archiving Releases.

Changes After Distribution

Once a release has been distributed, it is partially locked: asset composition, UPC, catalog number, release date, and the previously-released flag become read-only. See Lock Levels.

Other metadata can remain editable and can be redelivered without taking the release down. Examples include cover image, title, artist localisations, additional artists, label name, track titles, genre, P and C lines, publishing information, preview start time, explicit flag, territories, pricing tier, and sale start date.

Audio should only be replaced to correct a defect, while retaining the same ISRC and a similar duration. Acceptance of replacement audio remains subject to destination-specific requirements.

Structural changes—track order, track count, UPCs, or ISRCs—require a new release, as do substantive audio changes beyond replacing a defective file as described above.

When a change requires a new release:

1. Create a new release containing the required changes and distribute it.
2. Take the original release down with POST /supply-chain/v1/releases/{releaseId}/takedown.
3. Optionally rename the original with a - DO NOT DISTRIBUTE suffix. Nothing in the API enforces this; it is a convention that keeps the release from being submitted again by mistake.

See Changes you can and cannot make once your release is distributed.

Takedown Eligibility

A takedown is accepted only when the release has reached the store and is eligible to be removed. A release that is still in inspection, moving through the distribution pipeline, or already being taken down cannot be taken down again.

The release must also still carry the metadata a takedown notice needs: a UPC of at most 13 digits, and a stereo audio file and an ISRC for every track. A release that was distributed successfully normally satisfies this already, so these checks exist to catch edge cases—releases carrying incomplete or malformed data that would produce an invalid takedown notice. Validate Takedown reports them per store.

Validate Takedown is the authoritative check for takedown eligibility.

Two rules are particularly important:

• Takedown is all-or-nothing. If any requested store is ineligible, the entire request is rejected. Call GET /supply-chain/v1/releases/{releaseId}/takedown/validate first.
• Eligibility is per store. Check the individual store status rather than relying on the release’s inspectionStatus.

Takedown does not delete the release. The release, its history, and its events remain available after the takedown.

Deliver Release

curl -X POST "https://platform.revelator.com/supply-chain/v1/releases/8801/deliver" \
-H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d '{
  "distributorStoreIds": [1, 9]
}'

curl -X POST "https://platform.revelator.com/supply-chain/v1/releases/8801/deliver" \
-H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d '{
  "distributorStoreIds": [1, 9]
}'

true

true

curl -X POST "https://platform.revelator.com/supply-chain/v1/releases/8803/deliver" \
-H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d '{
  "distributorStoreIds": [9]
}'

curl -X POST "https://platform.revelator.com/supply-chain/v1/releases/8803/deliver" \
-H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d '{
  "distributorStoreIds": [9]
}'

{
  "type": "https://tools.ietf.org/html/rfc9110#section-15.5.1",
  "title": "One or more validation errors occurred.",
  "status": 400,
  "errors": {
      "General.Validation": [
          "Validate returned errors. Please call supply-chain/v1/releases/{releaseId:long}/deliver/validate endpoint first."
      ]
  },
  "traceId": "00-49e5db8eef8d8dc7afedefccc54619dd-6f0824ca71242c56-00"
}

{
  "type": "https://tools.ietf.org/html/rfc9110#section-15.5.1",
  "title": "One or more validation errors occurred.",
  "status": 400,
  "errors": {
      "General.Validation": [
          "Validate returned errors. Please call supply-chain/v1/releases/{releaseId:long}/deliver/validate endpoint first."
      ]
  },
  "traceId": "00-49e5db8eef8d8dc7afedefccc54619dd-6f0824ca71242c56-00"
}

curl -X POST "https://platform.revelator.com/supply-chain/v1/releases/99999999/deliver" \
-H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d '{
  "distributorStoreIds": [1]
}'

curl -X POST "https://platform.revelator.com/supply-chain/v1/releases/99999999/deliver" \
-H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d '{
  "distributorStoreIds": [1]
}'

{
  "type": "https://tools.ietf.org/html/rfc9110#section-15.5.5",
  "title": "Release not found for tenant 2001.",
  "status": 404,
  "traceId": "00-02a5d4051756b566ae491fc81152c957-deb355a180e79785-00"
}

{
  "type": "https://tools.ietf.org/html/rfc9110#section-15.5.5",
  "title": "Release not found for tenant 2001.",
  "status": 404,
  "traceId": "00-02a5d4051756b566ae491fc81152c957-deb355a180e79785-00"
}

Takedown Release

curl -X POST "https://platform.revelator.com/supply-chain/v1/releases/8801/takedown" \
-H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d '{
  "distributorStoreIds": [1]
}'

curl -X POST "https://platform.revelator.com/supply-chain/v1/releases/8801/takedown" \
-H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d '{
  "distributorStoreIds": [1]
}'

true

true

curl -X POST "https://platform.revelator.com/supply-chain/v1/releases/8802/takedown" \
-H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d '{
  "distributorStoreIds": [1]
}'

curl -X POST "https://platform.revelator.com/supply-chain/v1/releases/8802/takedown" \
-H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d '{
  "distributorStoreIds": [1]
}'

{
  "type": "https://tools.ietf.org/html/rfc9110#section-15.5.1",
  "title": "One or more validation errors occurred.",
  "status": 400,
  "errors": {
      "General.Validation": [
          "Release 8802 has no distributions to takedown."
      ]
  },
  "traceId": "00-1139c1f10a8949a0e0d6b32523380e4f-f6befe775349080a-00"
}

{
  "type": "https://tools.ietf.org/html/rfc9110#section-15.5.1",
  "title": "One or more validation errors occurred.",
  "status": 400,
  "errors": {
      "General.Validation": [
          "Release 8802 has no distributions to takedown."
      ]
  },
  "traceId": "00-1139c1f10a8949a0e0d6b32523380e4f-f6befe775349080a-00"
}