Organize one product for Etsy, Shopify, and eBay

Begin with one parent product for the item the customer recognizes. Add size, color, material, or bundle variants beneath it only when the option needs distinct product data. Keep the stable SKU, dimensions, materials, packaging, production files, and general description in that shared structure.

Then create a provider-specific map rather than flattening every channel into a single row. Store the remote listing, product, variant, inventory-item, or offer identifiers with the PlyOps product or variant they represent. Keep provider copy and required attributes in the matching marketplace slot.

Etsy's listing model can begin as an inactive draft. Variations are represented through listing inventory data that includes products, offerings, and property values. Publishing is a separate update to the listing state, so an Etsy draft and its variations should remain an Etsy-specific mapping.

Shopify uses a Product with options and variants. A product can have DRAFT status, and creating a product does not by itself publish it to sales channels. Publication is a separate concern, so Shopify status and channel publication should not be inferred from a PlyOps product being complete.

eBay's Inventory API separates inventory items from offers and can group related inventory items for a multiple-variation listing. Its publishOffer operation creates an active listing. PlyOps labels and confirms that final eBay step as live publication, even though an unpublished offer exists first.

A seller keeps one Wall Hook parent product in PlyOps with Small Black, Large Black, and Large White variants. The shared record holds production files, dimensions, material choices, packaging, and the general care text. Each variant keeps its own SKU and values that genuinely differ.

For Etsy, the seller maps those choices to one listing's variation products, offerings, and property values. For Shopify, the same choices map to a Product with Size and Color options and three variants. For eBay, each sellable SKU maps to an inventory item; related items can be assigned to an inventory item group and offers before the seller confirms live publication.

The identity stays shared, but the marketplace title, description, categories, attributes, remote IDs, and publication state stay with their provider. A change to the PlyOps general description does not become permission to overwrite three live listings.

A marketplace import should show the proposed product and variant matches before it writes to the library. Duplicate signals and remote IDs help find likely relationships, but the seller confirms which records belong together and how conflicts are resolved.

Where a provider supports an unpublished draft, PlyOps can prepare or create it only after checking required fields, showing a preview, and receiving your confirmation. An update starts with a fresh comparison. Because eBay's publishOffer creates an active listing, PlyOps labels that action as live publication and asks you to confirm it.

PlyOps does not publish connected listing changes in the background. Before sending a change, check the current category, policy, price, shipping, and provider requirements.

PlyOps stores product information, variant relationships, marketplace-specific copy, and the listing matches you confirm. It does not manage live marketplace quantities, promise every provider action is available, or bypass provider approval and account requirements.

Provider APIs and requirements change. Check the current integration status and the official documentation before a connected action. PlyOps does not become the marketplace ledger of record, manage live quantities, or bypass provider approval.