When you receive a SUBMIT_EVENT, its payload contains a submissionId. This page describes how to turn that ID into product data.

⚠️

Two different product ID namespaces

The submission endpoints use two distinct kinds of product identifier. Mixing them up is the most common integration error:

• Product ID — the product's identity in PDX. Returned by the family endpoints and used as input to POST .../products/channel.
• Submission Product ID — an identifier for one product within one submission. Used as input to POST .../products. It is not the same value as the Product ID.

Each endpoint below states which kind it expects.

Step 1 — Submission details

GET /external/submission/{submissionId}

Returns the submission's metadata: the channel, client, submission mode, and counts. Use it to decide how to process the submission.

Step 2 — Enumerate the submission's contents

For family-based channels, list the families in the submission, then the products of each family:

GET /external/submission/{submissionId}/familyIds
GET /external/submissions/{submissionId}/families/{familyId}/ids

familyIds returns the distinct family IDs in the submission. The second call returns the Product IDs of every product belonging to that family.

Families and variants

Products are grouped into families through the familyId field on each product:

• All products sharing the same familyId belong to the same family.
• Standalone products (no family) have familyId = null.
• There is no aggregate "family object": you fetch the family's products and group them yourself using familyId. Whether a product acts as the family-level record or a variant is determined by your datastandard's family modeling (see Families), not by a flag on the submission product.

Step 3 — Fetch product data

Fetch by submission product IDs

POST /external/submission/{submissionId}/products
{ "submissionProductIds": ["..."] }

Returns the full product payloads (attributes, language attributes, levels) for the given Submission Product IDs.

Fetch the receiver split

POST /external/submission/{submissionId}/products/channel
{ "productIds": ["..."] }

Input is a list of Product IDs. The response tells you which receiver each product was submitted to:

{
  "productsPerChannel": {
    "my-channel#receiver-a": ["product-1", "product-2"],
    "my-channel#receiver-b": ["product-1"]
  }
}

• Each key is a receiver channel ID of the form {channelId}#{receiverIdentifier}.
• Each value is the list of Product IDs that were valid for and submitted to that receiver.

A product appears under a receiver only if it was actually submitted to that receiver, so the same product can appear under several keys (submitted to multiple markets) or under only some of them (not valid for every receiver). Use this endpoint when your channel uses receivers and your target system needs a per-market/per-feed split. For channels without receivers you can skip it.

Receiver data inside the product payload

For channels with receivers or hierarchy levels, each product's payload contains per-level attribute values in its levels array:

{
  "productId": "product-1",
  "attributes": [ ... ],
  "languageAttributes": { "en-US": [ ... ] },
  "levels": [
    {
      "token": "my-channel",
      "attributes": [ ... ],
      "languageAttributes": { ... },
      "levels": [
        {
          "token": "receiver-a",
          "attributes": [ ... ],
          "languageAttributes": { "de-DE": [ ... ] },
          "levels": []
        }
      ]
    }
  ]
}

How to read it:

• The top-level attributes / languageAttributes hold the product's global values.
• Each entry in levels is one node of the channel hierarchy. The token identifies the node: the root node's token is the channel ID; a receiver node's token is the receiver identifier — the same identifier used in the productsPerChannel keys ({channelId}#{receiverIdentifier}) and returned by the receivers endpoint.
• A level's attributes / languageAttributes contain the values specific to that level — for a receiver node, the receiver-specific overrides (for example, market-specific descriptions or the receiver's languages).
• Values not overridden at a level fall back to the level above it, ultimately to the product's global values. Apply this fallback when building the per-receiver output.

To resolve a receiver token to its full configuration (name, properties such as the receiver's language), list the channel's receivers:

GET /external/channels/receivers/clients/{clientId}/channels/{channelId}

Each receiver has an identifier (matching the level token), a name, and a properties map. Receivers are configured by PDX users in the PDX application; this endpoint is read-only.

Packaging hierarchies

For channels that submit packaging hierarchies, the hierarchy structure is available separately:

GET /external/submissions/{submissionId}/packagingHierarchies

Reporting status

After delivering (or failing to deliver) the data, report back so the PDX user sees the outcome:

• POST /external/submit/status — the overall submission status.
• POST /external/submit/items — per-item statuses, so users can see which products succeeded or failed and why.

Status handling semantics are shared with SDK adapters and described in Status Handling.