commerce_create

Create the exact X00004 product draft prepared by commerce_creation_get. Explicit sale and visibility settings can make the product available when executed. This creates product configuration, not an order, payment, shipping dispatch or refund.

Connected source: Only X00004 is registered through this connection. There are 153 source registrations versus the older recorded 145-tool runtime; inspect current discovery.

Inputs

Require channelCode, pAppCode:X00004, the entire unchanged draft from the preparation contract, stable requestId and expectedRevision. requestId is 8–80 ASCII letters, digits, underscores or hyphens. Copy the preparation result's revision into expectedRevision, a 64-character lowercase hexadecimal string. dryRun is optional, default false.

All draft fields, defaults, single/combined options, currency limits, image order and initial stock rules are the same as preparation. Use only completed product-image task IDs for this exact current connection, operator, credential version, installed shop, purpose and storage. No caller image URL, raw create body, service route or credential override is accepted. Changing the draft requires preparing it again; do not reuse an existing product's settings/control revision.

The common connection must resolve the existing store, configured BCS/COMMERCE_V2 origin, image storage and current authorization. The source does not create a missing store or infer service configuration. Legacy X00002 and ticket-event drafts remain unconnected even though owner-domain schemas exist.

Save, identity and recovery

A fresh dry run returns COMMERCE_OPERATION_PLAN, the planned request/dependencies/images and writesPerformed:false without creating a new job or sending the create. A dry run against an existing task is historical inspection, not a fresh completion check.

The real call persists prepared then sent before one source POST. HTTP 200 must contain the product record; the existing-product success/action dispatch receipt is not the create contract. The returned exact product identity must be parsed and durably saved. The workflow then reads that product and its dependencies twice. A receipt alone is not completion.

The returned resourceId must equal the saved productId. New option/image/variant IDs must be distinct and internally consistent. Access-control absence in the source DTO is not proof of an unreturned backend field. Readback does not prove exclusive causality, atomicity, public rendering, stock availability at checkout or customer purchase behavior.

Use taskType commerce-creation. Central status reports historical saved progress; resume only observes and cannot dispatch prepared or sent work. Unattempted prepared work needs the identical original create call after revalidation. A sent request without saved identity stays pending/COMMERCE_CREATE_UNKNOWN: no title matching, inventory scan, identity adoption or resend is permitted. With a saved identity, recovery only reads that exact product. Readback differences remain COMMERCE_OPERATION_PENDING with a diagnostic lastCode. Keep the original task; never bypass uncertainty with a new requestId. Inspect saveAcknowledged and journalPersistence separately from verified completion.

Completed replays are historical with current verification false and no fresh success link. Read commerce_product_settings_get for current state. Verified fresh preparation/dry run opens products/create; verified creation opens the exact created product. Pending, mismatched and historical results do not gain a current success destination.

There is no automatic deletion, orphan-image cleanup, rollback or identity-preserving undo. Discontinuing or hiding a created product does not restore its prior absence. Initial input/add-on options have the later bounded contract below; existing-product group/item creation remains unavailable.

Input example

Illustrative dry run of the preparation example. Replace the all-zero expectedRevision with that call's returned revision and retain the complete intended draft. Image-task and dependency identities must actually exist in the same authorized context.

{
  "channelCode": "selected-channel",
  "pAppCode": "X00004",
  "requestId": "shop-create-001",
  "expectedRevision": "0000000000000000000000000000000000000000000000000000000000000000",
  "draft": {
    "name": "Sample notebook",
    "slug": "sample-notebook",
    "price": "1000",
    "originalPrice": null,
    "imageTaskIds": ["shop-image-001"],
    "returnPolicyContent": "Use the existing store return policy.",
    "shippingPolicyId": "observed_shipping_policy",
    "saleStatus": "DISCONTINUED",
    "visibilityStatus": "DISABLED",
    "options": {"kind": "single", "sku": "NOTEBOOK-01", "quantity": 10}
  },
  "dryRun": true
}

Creation SEO connection boundary

MCP adds optional seoTitle, seoDescription, seoKeywords and seoImgAltText to the X00004 draft. Older drafts omitting all four fields retain their prior contract.

Explicit requested blanks/keyword arrays participate in exact created-product readback while omitted fields stay absent. Obtain a fresh preparation revision after changing metadata, retain the complete draft and original request identity, and never resend a sent create to repair missing metadata or a lost product ID. The existing shared status/resume observation rules and lack of rollback are unchanged.

Initial input and add-on children

MCP extends the complete creation draft with one optional input field and one optional nonrequired add-on group of1–3 items. These are part of one whole-product CREATE, with the same commerce-creation task and parent product receipt.

Readback validates requested child fields and exact parents/store/currency/ordering with distinct consistent IDs over two stable product reads. It does not independently pin every child ID to the historical CREATE response. Missing parent receipt cannot be repaired with child matching or another create. No new group/item creation on an existing product, checkout validation, automatic deletion or restoration is added.