Shoptet Multishop lets a merchant run several online stores from a single project and a single administration. Until now, a project meant one domain, one language set, one currency set and one storefront. With Multishop, one project can contain a Czech store on a .cz domain in CZK, a Slovak store on a .sk domain in EUR and a Hungarian store on a .hu domain in HUF, all sharing the same catalogue, stock, customers and orders.
This changes a few assumptions that most add-ons were built on. If your add-on reads shop settings, works with orders, filters products, or configures anything per shop, you will need to make it aware of sales channels. This chapter explains the concept, lists the API changes that are already live, previews what is coming, and gives you a migration checklist.
Deadline: add-ons that need per-channel behaviour should be adapted preferably by the end of 2026. Multishop is already available to merchants on Premium, Profi and Enterprise plans.
| Shared across the whole project | Specific to each online store |
|---|---|
| Products and catalogue | Domain and DNS |
| Stock (intentionally a single warehouse) | Language, currency, delivery countries |
| Customers | Payment and shipping methods |
| Orders (one order list in one administration) | Contact information |
| Billing company | Tracking codes (GA4, Seznam, Facebook pixel) |
| Heureka and other add-on specific settings |
Every project, Multishop or not, already has one default sales channel. Multishop simply adds more. This is why the API model below applies to every project you integrate with, not only to Multishop projects.
A sales channel is the place where a sale happens. Every order is created in exactly one sales channel, and several settings (visibility, payment and shipping methods, price lists) can differ per channel.
Each sales channel is identified by a GUID. In the API this GUID appears as salesChannelGuid (SCHID). Treat it as the primary identifier of a channel and store it in your add-on.
type |
Meaning |
|---|---|
online_store |
An online store (one domain, language and currency set) |
in_store |
A physical store, or a cash desk that belongs to a physical store |
marketplace |
A marketplace integration (for example Allegro). Orders are read-only through the API. |
system |
Internal system channel |
The query parameter salesChannelGuid is added everywhere the result depends on a specific sales channel. There are two patterns:
salesChannelGuid as a query parameter and return channel-specific data.salesChannelGuid is an attribute in the order request and response, not a query parameter.Entities that are shared across channels (stock, customers, categories) do not take the parameter.
| Endpoint | Purpose |
|---|---|
GET /api/sales-channels |
List of all sales channels |
GET /api/sales-channels/{guid} |
Detail of one sales channel by GUID |
GET /api/sales-channels/id/{id} |
Detail of one sales channel by numeric ID |
More info on endpoints structure can be found in technical specification: https://api.docs.shoptet.com/shoptet-api/openapi/sales-channels
Register these webhooks to keep your copy of the channel list current:
| Event | Identifier in the webhook |
|---|---|
salesChannel:create |
GUID of the sales channel |
salesChannel:update |
GUID of the sales channel |
salesChannel:delete |
GUID of the sales channel |
GET /api/eshopThe existing GET /api/eshop endpoints describe the project as a single shop. They keep working for now, but they will be marked as deprecated later. For anything that can differ per online store (domain, languages, currencies, countries, payment and shipping methods), start reading it from the sales channel endpoints instead.
Orders are firmly bound to the sales channel they were created in, so salesChannelGuid is part of the order payload rather than a query parameter.
GET /api/orders, GET /api/orders/{code} and the order snapshot return salesChannelGuid.salesChannelGuid filter. It matches exactly the channel you pass.source object and sourceId are deprecated and are replaced by sales channels. source.id is already documented as deprecated.POST /api/orders accepts salesChannelGuid. Use it instead of sourceId.marketplace sales channel through the API. Marketplace orders are created by the marketplace integration; reading them works as for any other order.| Endpoint | Change |
|---|---|
GET /api/shipping-methods |
Optional query parameter salesChannelGuid. Without it, all shipping methods are returned. |
GET /api/payment-methods |
Optional query parameter salesChannelGuid. Without it, all payment methods are returned. |
If your add-on offers a payment or shipping method to customers, call these endpoints with the GUID of the online store the customer is shopping in. The same method may be enabled in one store and disabled in another.
salesChannelGuid query parameter and the response will contain channel-dependent attributes, visibility above all. Plan for the parameter to be present on every product request your add-on makes. A dedicated endpoint for linking products to a sales channel is also planned. Exact behaviour will be announced in the API release news before release.primaryOnlineStoreGuid field on customer list, detail and snapshot. It reflects the customer’s primary online store set at registration, not anything derived from orders.All new endpoints connected to Multishop are subject to change until they are announced as final. Follow the API release news on developers.shoptet.com.
salesChannel:* webhook, call GET /api/sales-channels and store guid, type, parentSalesChannelGuid, name, domain, default language and default currency per channel.GET /api/eshop with per-channel values from the sales channel detail.salesChannelGuid instead of source and sourceId. When creating orders, send salesChannelGuid. Never use a marketplace channel for creation.salesChannelGuid of the store the customer is in.salesChannelGuid on product requests and to handle visibility that differs per channel.