Shop products, creation and inventory

Source connection: These four new registrations are later than the recorded 145-tool runtime; discover the connected endpoint before use.

The original four-method connection configures existing X00004 products. Three creation/image methods are described below. Existing-product editors do not restructure options or edit detailed pages; none of these methods configures shipping policies, buys, pays, fulfills orders, refunds or settles.

Connection and authorization

Select the exact authorized channel. The host must configure PUBL_COMMERCE_V2_API_ORIGIN, or commerceV2ApiOrigin in the standalone runtime profile. Hosted configuration requires an explicit HTTPS origin. COMMERCE_V2 is the BCS service, separate from legacy COMMERCE, PAY and the account API; there is no guessed default or alternate-service fallback. These are host settings, not tool arguments. Never provide tokens, headers or service URLs in a call.

The connection verifies channel ID/code/currency, the operator's channel binding, one installed X00004 entry and its detail, and the existing store ID from store-default-setting. Product traffic uses that installation's consumer identity; account/channel discovery uses its separate header context. The caller supplies no pAppCode, installedPAppId, storeId or currency override. Business IDs are 1–160 letters, digits, underscores or hyphens and must come from observed records, not numeric row IDs, titles or URLs.

OWNER is permitted. A DELEGATEE requires MANAGE_P_APPS and a freshly observed public manual-action policy proving the channel is not content-only. The host tries the configured primary policy URL and source fallback as needed. Array membership or an own record key marks the channel content-only even when its value is false. Missing, malformed, oversized or unavailable policy fails closed; it is never an empty permissive policy. Public policy requests carry no token or channel/consumer header. Current grants and the exact store, currency, actor and installation are rechecked around requests. A changed context cannot adopt an old task. Account scope and foreign channel resources are excluded.

Plan, save and recover

For controls, read an exact product/variant selection and copy its revision; paged inventories do not provide a mutation revision. For settings, use the selected product settings revision. Both writers require a stable 8–80-character requestId (letters/digits/underscores/hyphens), a fresh 64-character lowercase hex expectedRevision and explicit intended fields. Start with dryRun:true; inspect the planned request. Dry run makes no business write and no new journal. Omitted settings are preserved.

COMMERCE_OPERATION_PLAN describes a plan, with current verification false. A no-op completes without dispatch. A changed request records prepared then sent before one source dispatch. The adapter requires HTTP 200 with success:true and the expected action echo, except that bulk variant sale status may omit the echo (a supplied echo must match). An acknowledgement is insufficient: fresh stable readback must match requested and preserved fields. Partial bulk outcomes, response/context uncertainty or readback differences remain pending. There is no atomic snapshot, backend compare-and-swap or proof that this task was the only writer.

Use taskType commerce-product-control or commerce-product-settings, matching the original writer and taskId. Central task_status reports historical saved progress under current authorization. Central task_resume only observes sent effects; prepared work needs the identical original apply. A separate guard blocks recovery writes even if a saved phase changes concurrently. Once sent, a request is never repeated, including after response loss or partial bulk changes. The known selected records may be reconciled by observation without an acknowledged receipt. Do not switch requestId to retry uncertainty or promise rollback.

COMMERCE_OPERATION_COMPLETE means matching stored state; COMMERCE_OPERATION_PENDING retains unresolved work. Inspect phase, saveAcknowledged, lastCode and journalPersistence. Completed replay is historical with current verification false and no current console link. Use a fresh reader for current values. Credential, grant, connection, store, currency or installation drift requires resolving the binding, not substituting credentials.

Destinations and limits

Fresh reads, plans and confirmed saves return one validated configured-console destination. One product opens its product detail; one variant opens stock-change history. Multiple products/variants use the surviving parent product/stock list and identify it as a parent. Paged reads retain supported filters/page size. No dry-run link proves a save, and historical/pending/error results have no current usable destination. Use returned URLs rather than constructing a host.

COMMERCE_CONTEXT_MISMATCH/CHANGED and COMMERCE_PERMISSION_DENIED require resolving the current context. COMMERCE_CONFLICT requires a fresh matching read for an intended unsent edit. Invalid product/currency/association or unknown option data must not be coerced into a partial save. Uncertain sent work remains observation-only. Configuration verification does not prove checkout, visitor visibility, stock availability for a purchase, fulfillment or financial completion.

Create a new shop product

The static source inventory advances to 153; the older recorded runtime remains 145 and was not rediscovered here.

1. Use commerce_image_upload with original PNG/JPEG/GIF bytes strictly below 3 MiB and purpose product. It requires explicit RESOURCE_GATEWAY origin/bucket/region plus the existing exact shop context. Only a completed upload task can be referenced; dry run or image acknowledgement does not create a product.
2. Submit the entire intended draft and completed imageTaskIds to commerce_creation_get. It verifies same-store dependencies and image bindings and returns revision; changing the draft requires preparing again.
3. Copy that revision into commerce_create expectedRevision, keep the draft unchanged and use a stable requestId. Single/combined options, initial stock and explicit sale/visibility are supported. A returned exact product identity and two matching observations are required before completion.

These new task types are commerce-image and commerce-creation. Shared status/resume are observation-only; prepared work requires identical original input, and sent upload/create uncertainty never replays. Unknown create identity cannot be inferred from a matching title. Image references bind current credential version and storage as well as the operator/installation, so refresh can invalidate reuse. Completed replay is historical; use a fresh product reader. Ready plans open products/create, acknowledged unattached images identify that creation screen as a handoff, and verified creation opens its exact product. No automatic image cleanup, product deletion or rollback is provided.

Existing-product buyer input field

MCP adds settings.inputOption create/edit/remove for one buyer-entered field on an existing X00004 product. Use the product-settings revision; title and placeholder are required 1–50-character trimmed values. Edit/remove require the exact existing field identity, and removal requires REMOVE_PRODUCT_INPUT_OPTION. Creation must persist the new business field ID from the REVISE result before stable readback; response loss never permits title adoption or resend. Preserve other product fields and old journals. This does not add an initial input field to commerce_create or modify order answers. It preserves the original REVISE result and durable returned identity. That record remains standalone evidence; Actual console/checkout/restoration and running-service behavior remain unverified.

Edit or remove existing paid add-ons

MCP adds settings.addons edit/removeItems/disable on existing X00004 products. Use the product-settings revision and exact existing group/item IDs. One group with one to three items is supported; selected removal must leave at least one, while explicit disable clears the whole configuration. Requiredness changes remain unavailable.

Add-on prices follow their source control: zero through 9,999,999,990 in both currencies, KRW integer steps of 100 and USD steps of 0.01. These differ from product prices and new variant adjustments. Preserve unrequested fields, identities, requiredness and unrelated product data. Sent recovery only observes, and removal does not promise physical deletion or original-ID restoration. Combining with inputOption.create retains that field's durable creation-ID requirement. Matching add-on values never replace a missing input receipt, and drift remains pending.

Optional creation SEO through the shared host

The existing X00004 creation draft gains four optional SEO fields. Omission is distinct from an explicit blank; keyword order and duplicates are retained under the original bounds. Read the complete contract before preparing a new draft. Older drafts without SEO fields retain the connected creation contract. Actual indexing, visitor metadata/image rendering, console comparison and restoration remain unverified.

Create a product with initial buyer options

MCP adds inputOption and addons to X00004 creation: one input field and one nonrequired add-on group with1–3 choices. Omission keeps prior empty arrays; exact source text/currency bounds and full-draft preparation still apply.

Add buyer choices to an existing product

Create one nonrequired group with1–3 items only when no group exists, or append one item to the exact group while keeping a maximum of3. Retain the observed product/store/currency and all existing identities and values. Use the add-on price bounds, which differ from product/variant prices.

Successful REVISE must return the new group ID or exactly one new item ID, then the task must persist it before stable readback. Group children have stable-observation scope within that returned group, not historical equality to every response child ID. Missing receipts never permit name matching or resend. Independent input-field creation must be a separate request because the task stores one receipt. Strict success/action/result, one durable identity and two stable reads remain required; missing receipts never permit another save or inferred adoption. Fixture cleanup compares configuration only, not physical erasure or original child-ID restoration. Actual saves, console, buyer charges, old orders, restoration and hosted/LLM behavior remain unverified.

E00002 retirement is separate from commerce

This does not remove X00002 commerce or its retained product, stock and shipping behavior, and it does not change this guide's X00004 COMMERCE_V2/BCS contract. E00003 tickets retain BOOK_AND_TICKET_V3. Preserve existing task records and never substitute another pApp code to continue an uncertain retired ticket operation.