Feature request: A generic sales channel plugin structure

[talhakaanozkan]

Hi,

Many stores sell not only on their own website but also on external sales channels such as marketplaces and social commerce platforms. Managing products, stock and orders separately on each channel is time-consuming and error-prone.

GrandNode2 has a clean plugin structure for payment and shipping providers. A similar structure for sales channels would make these integrations much easier.

Suggestion

1. Sales channel provider interface: A common interface (e.g. ISalesChannelProvider) that plugins can implement for each channel.
2. Product sync: Sending products, variants, images, prices and descriptions from GrandNode2 to the channel, with the option to choose which products are listed on which channel.
3. Stock and price sync: Automatically updating stock and prices on all channels when they change in GrandNode2.
4. Order import: Importing orders from channels into GrandNode2, so all orders can be managed in one place, and sending order status and tracking updates back to the channel.
5. Category and attribute mapping: A way to match GrandNode2 categories and attributes with each channel's own categories and attributes.
6. Admin panel: A screen to see sync status, errors and logs for each channel.
7. Channel-specific pricing (optional): Setting different prices per channel, for example to cover commission differences.

Questions

• Would you consider adding a sales channel plugin structure to GrandNode2?
• If it's not planned soon, what would be the recommended way to implement such an integration within the current structure?

Thanks for the great work on GrandNode2!

[KrzysztofPajak]

Hi @talhakaanozkan, thanks again, this one is closely related to #915. Multi-channel selling is a real need, and we agree it should go through a standard extension point rather than one-off integrations.

What can be done with the current structure:

• Product and stock sync (outbound). Stock changes made through IInventoryManageService publish UpdateStockEvent and EntityUpdated<Product>. Product edits publish EntityUpdated<Product>, and automatic publish/unpublish on low stock publishes ProductPublishEvent / ProductUnPublishEvent. A plugin can handle these and push changes to a channel. A scheduled task is a good place for batching and retries, since channel APIs are rate-limited.
• Status and tracking (outbound). OrderPaidEvent, ShipmentSentEvent and OrderCancelledEvent can be used to report order progress back to the channel.
• Order import (inbound) is the real gap. Order placement today is built around the storefront checkout: cart, customer, payment, and recalculated prices, discounts and taxes. An order coming from a marketplace is already priced and paid, so it does not fit that flow cleanly. The order also has no standard field for its source channel or external id.

What a proper sales channel structure would need:

1. Complete stock events. Every stock change, including attribute combinations, reservations and per-warehouse stock, would have to publish an event, so a sync plugin never misses one. Not every such change does today.
2. An "import external order" path. It would take an already-priced, already-paid order, reserve stock, assign an order number and trigger the usual notifications, without going through the cart or a payment provider. It would also store the source channel and external order id. This is the part that needs the most care, because it touches checkout.
3. Channel-specific logic kept in plugins, at least at first: category and attribute mapping, product selection per channel, sync logs, and per-channel pricing. Every marketplace models variants, categories and required attributes differently, so a generic core interface designed up front would likely end up either too thin or too opinionated. Once one or two real integrations exist, the common parts (sync queue, error log, mapping storage) are much easier to identify and share.

Recommended approach today: a plugin with handlers for the product/stock/order events above, a scheduled task that pulls new orders from the channel, and a mapping store in the plugin's own collection. Order creation is the weak spot for now. If you have a concrete channel in mind, sharing what its order and product APIs require would help clarify what an import contract should look like.

[talhakaanozkan]

Thank you for your detailed and kind response. As you said, there can be a lot of channel-specific differences between sales channels. I’ll run my tests through a few sales channels in Turkey and share here what the process looks like.

[talhakaanozkan]

Hi, thanks for the detailed and clear answer. The breakdown of what is possible today (event-driven outbound sync in a plugin) versus what is missing (an "import external order" path and a source channel / external id on the order) is very helpful, and I agree that channel-specific logic should stay in plugins at first.

One thing I would like to add to the discussion: in our case, "sales channel" is not only about marketplaces. In another project we are planning the following channels under one backend:

• Web (the storefront itself)
• Physical store (POS)
• B2B (a separate customer portal)
• Marketplaces

These cases share the same core needs: a way to define a channel, choose which products are available on it, tie inventory to it, and record which channel an order or cart came from. That is why I think a lightweight channel concept in the core (even before any marketplace-specific provider interface) could be valuable, since it would serve POS, B2B and marketplace integrations alike.

For reference, here is how other platforms approach it:

• Medusa Sales Channel Module (open source): https://medusajs.com/sales-channel-module. Channels are a first-class concept. Product assortment and inventory are curated per channel, and carts and orders are associated with a channel, which enables per-channel order views and analytics.
• Shopify sales channels: https://www.shopify.com/tr/channels
• Shopify POS: https://www.shopify.com/tr/pos

Based on your comments, a possible minimal first step could be:

1. A channel entity (id, name, type) that can be linked to products, and optionally to stores/warehouses for inventory.
2. A source channel and external order id on orders and carts.
3. The "import external order" path you described, which would serve both marketplaces and POS.

Everything else (mapping, sync queues, per-channel pricing) could stay in plugins as you suggested.

Thanks again for the quick and thoughtful response!