Publish monitoring & control

List the account's background publish operations — scope "active" (queued and running, the default) or "recent" (the newest of any status) — each with its status, the stores it targets, progress counts (total, completed, succeeded, failed), the failed items with their reasons, and whether it holds the whole account locked. At most 50.

Get one background publish operation: its status (queued, running, completed, canceled, failed), whether a cancel was requested, the stores it targets, progress counts, the failed items with their reasons, and its timestamps. Poll this after publish_master_v1 or publish_batch_v1 accepted a run.

Get the item-by-item recap of a publish operation, failures first: each item's label and type, its outcome, the per-store split (which stores took it, which refused it and why), and the changes the run pushed — field before/after values per store, including the relationship rows a collection's sources produced (Products added/removed, excluded products/collections added/removed). Capped at 500 items; total reports the run's real size.

For one item, read each store version's last publish outcome: the status, the merchant-facing reason Shopify (or the publish) gave when it failed, the fields held responsible for that failure, whether it still has unpublished changes, and when it last published. The reason wording is the same the detail page shows; a store with no failure reports its status only.

Inspect what a publish of one item would carry, against the published baseline: the shared (all-store) field changes, and per store the field before/after changes plus the RELATIONSHIP changes still awaiting Shopify — media attachments, hand-picked collection memberships, collection-source edits, catalog and market attachments — with whether the store version was ever published and whether its last publish failed. For a product, the variants that owe changes are included (bounded). Publish-minted identifiers are never listed as changes.

Ask which of up to 500 items are currently locked by a running publish operation — and why (the item is a publish target, a dependency of one, or its relationships are being reconciled) — plus whether the whole account is locked. A locked item refuses writes with publish_lock_conflict until the operation named finishes.

List the publish-completion notifications the finished operations left for the connected identity: the operation, its status and counts, the stores, the entity it was about, the leading changed fields, and whether it was read. An identity the notifications are not addressed to gets an empty list. At most 50.

Cancel a queued or running publish operation. The worker requests cancellation within a second, aborting in-flight Shopify calls; unreached and interrupted items stay pending, and the run ends as canceled. Nothing already published is undone. Canceling an already-finished operation is a no-op that returns it unchanged.

• Extended timeout. 120 s per call — the operation runs server-side orchestration or a live Shopify read.
• Reaches your stores. Annotated open-world and destructive; the in-app assistant always asks for confirmation before running it.

Publish many items LIVE to Shopify as ONE background operation — either master_ids with a shared channel_ids (empty channel_ids = every store each item is on), or targets with each item's own stores (the cross-store grid form). Same accept-and-enqueue admission as publish_master_v1: the result is the accepted operation (poll get_publish_operation_v1, then read its recap); a conflicting running publish answers 409 publish_lock_conflict, and more than 20 active operations are refused. At most 10000 targets.

• Extended timeout. 120 s per call — the operation runs server-side orchestration or a live Shopify read.
• Reaches your stores. Annotated open-world and destructive; the in-app assistant always asks for confirmation before running it.