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. That final eBay step is a reviewed live action, even though an unpublished offer exists beforehand.

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 a reviewed publication step.

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 validation, preview, and explicit confirmation. An update needs a fresh comparison for the same reason. Because eBay's publishOffer creates an active listing, PlyOps must label and confirm that action as live publication rather than describing it as draft creation.

No connected workflow silently publishes in the background. The seller remains responsible for the final marketplace review, including current category, policy, price, shipping, and provider requirements.

PlyOps stores product information, variant relationships, marketplace-specific copy, and reviewed mappings. It does not manage live marketplace inventory quantities, promise that 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.