Skip to main content
Once a release reaches ready status in the UMW catalog, you can submit it for delivery to one or more digital stores. The delivery workflow lets you choose target stores, specify territory availability, monitor ingestion progress per store, and respond to any content issues that arise during a retailer’s review process. This guide covers the full delivery lifecycle from store selection to confirmed availability.

Delivery Lifecycle

Every delivery moves through a defined sequence of statuses. Understanding these states helps you build reliable polling logic and know when human intervention is required.
Subscribe to the delivery.completed webhook event to receive real-time notifications when a delivery reaches a terminal state (delivered, rejected, or action_required) instead of polling the status endpoint. See the Webhooks guide to set up your endpoint.

Step-by-Step: Delivering a Release

1

List Available Stores

Retrieve the current list of supported digital stores along with their supported territories and delivery capabilities. Use the store_id values returned here when constructing your delivery request.
Query parameters:Sample response:
2

Submit a Delivery

Create a delivery order by specifying the release, target stores, and the territories where the release should be available. You can deliver to all supported store territories by passing "WORLDWIDE" in the territory_codes array.
Request body:
Response:
Store the id value as your delivery_id for status polling.
3

Monitor Delivery Status

Poll the delivery endpoint to track progress. Each entry in the stores array reflects the per-store ingestion state independently, so some stores may confirm delivery before others.
Sample response (in progress):
The top-level status field reflects the aggregate state across all stores. It will not advance to delivered until every store in the delivery order has confirmed availability.
4

Handle Rejections and Action-Required States

If a store rejects a delivery or flags an issue, the delivery status will change to rejected or action_required. Inspect the per-store rejection_reason field to understand what needs to be corrected.Sample rejection response:
Resolution workflow:
  1. Review the rejection_reason and rejection_code for each affected store.
  2. Update the relevant release or track metadata using PATCH /v1/releases/{release_id} or PATCH /v1/tracks/{track_id}.
  3. Resubmit the delivery to the affected stores only:
Do not create a new delivery order to fix a rejection on an existing delivery. Use the resubmit endpoint to avoid duplicate delivery records and potential duplicate-content flags at the store level.

Managing Takedowns

To remove a release from stores, issue a takedown request against an existing delivery:
Takedowns typically propagate within 24–72 hours depending on individual store processing times. The delivery status will update to taken_down once all requested stores confirm removal.