What should you sync from MoySklad to an online store?

TL;DR

• MoySklad can be the source of truth for stock without becoming the source of every word, image and category customers see.
• For We Nera, a Kazakhstan fashion brand, Magaz synchronized availability for 114 products and 309 size variants at launch in May 2026.
• Product photography, customer-facing titles, Russian and English content, navigation and seasonal collections were managed separately in the storefront.
• The main lesson was not to synchronize as much data as possible. It was to synchronize only the data each system could reliably own.

Key facts

• One live implementation: We Nera, a fashion brand based in Almaty, Kazakhstan.
• Launch date: May 2026.
• Catalog at launch: 114 products and 309 size variants.
• Inventory setup: one MoySklad warehouse supplying physical retail, Instagram, wholesale and the online store.
• Data synchronized for this client: stock availability for products and size variants already linked between MoySklad and Magaz.
• Data managed separately in the storefront: images, customer-facing titles and descriptions, Russian and English content, navigation, seasonal collections and other merchandising.
• Currencies at launch: KZT, KGS and EUR.
• Customer-facing stock: shoppers see which sizes are available, not the internal quantity.
• Order flow: customers prepare an exact order and send it to the store through WhatsApp; payment is completed by QR code.
• Update cycle: as of July 2026, We Nera introduces new collections approximately once a month.

Disclosure: Magaz built and operates the We Nera storefront. The implementation details and numbers in this article come from that client project. They describe one store, not every MoySklad integration.

Can MoySklad power an online store?

Yes. MoySklad can provide the operational data an online store needs, including stock, product identifiers, variants, prices and orders, depending on how the integration is configured.

The more important question is not whether the two systems can exchange data. It is:

Which system should be responsible for each part of the customer journey?

MoySklad describes itself as a cloud ERP for managing trade, inventory and production. That is its strength. It gives a retailer one operational system for products, stock movements, purchases, sales and other internal processes.

An online store has a different job. It must help a customer discover the right product, understand it, choose a size, trust the presentation and complete the next step.

Those responsibilities overlap, but they are not identical.

A product record can be perfectly adequate for warehouse operations and still be unsuitable for a customer-facing product page. The internal title may be technical. The image may be missing. Products may be grouped for accounting or warehouse convenience rather than for shopping. A seasonal edit or campaign may not belong in the inventory structure at all.

That is why a successful MoySklad integration is not necessarily the one that copies the most data.

Our first approach synchronized too much

At the start of the We Nera implementation, Magaz synchronized more product information from MoySklad than the storefront ultimately needed.

On paper, copying more fields sounds efficient. If a product already exists in MoySklad, why prepare parts of it again for the website?

The problem was data ownership.

The MoySklad catalog was maintained as an internal operational tool. Product names were not always written as customer-facing fashion titles. Some records did not yet have the images required for a premium store. The internal product grouping did not include every collection, seasonal story or curated navigation path that customers needed.

Magaz also had higher expectations for how the assortment should be presented. The storefront needed consistent photography, clear titles, useful descriptions, English content and navigation built around product discovery.

The integration was therefore narrowed.

MoySklad remained authoritative for the information it could own reliably: stock availability for linked products and variants.

The storefront became authoritative for presentation: images, titles, descriptions, translations, categories, seasonal collections and merchandising.

This was not a workaround. It was a clearer division of responsibility.

An inventory system should optimize operations. An online store should optimize buying.

Inventory records and storefront content solve different problems

The two systems can describe the same product without serving the same audience.

The We Nera website demonstrates this separation publicly.

Customers can browse product-type categories such as Dresses, Shirts & Tops, Pants & Skirts, Jackets & Vests and Accessories. They can also browse customer-facing edits such as Bride’s Farewell and Stylist’s Edit. Those groupings help shoppers discover and style the collection. They do not need to reproduce the warehouse structure.

The site also presents Russian and English content and prices in KZT, KGS and EUR. These are storefront decisions. They do not require the internal inventory record to become a complete multilingual merchandising system.

What should be synchronized from MoySklad?

There is no universal answer. The correct scope depends on which system the retailer trusts to own each field and what should happen when the same field changes in both places.

A useful starting point is to ask five questions:

1. Which system is the source of truth for stock?
2. Are product and variant identifiers stable and correctly matched?
3. Should website orders create orders or reservations in MoySklad?
4. Which system owns prices and discounts?
5. Is the MoySklad product content ready to be shown directly to customers?

For We Nera, the answer was deliberately narrow.

This setup should not be copied blindly by every retailer.

A business with standardized product records and a conventional card checkout may prefer to synchronize titles, images, prices, orders and reservations as well. A store that closes orders manually through WhatsApp may need a different boundary.

The principle is simple:

Synchronize a field only when the receiving system should trust and inherit that field.

Case study: We Nera

We Nera is a Kazakhstan fashion brand with a physical presence in Almaty and an assortment that is also sold through Instagram, wholesale and its own online store.

At launch in May 2026, the online catalog contained:

• 114 products;
• 309 size variants;
• Russian and English;
• KZT, KGS and EUR;
• high-quality customer-facing product images;
• customer-facing product categories and collections;
• structured ordering through WhatsApp.

The brand had one MoySklad warehouse. The complexity did not come from the number of warehouses. It came from several sales channels drawing from the same assortment.

A size sold through the physical shop or another channel should not continue to appear as available online. Without synchronization, the team would need to check stock manually before confirming each order, and the website could show sizes that had already been sold.

Magaz matched the product and size variants already prepared in the storefront with their corresponding MoySklad records. When stock-changing activity is recorded in MoySklad, Magaz refreshes the available inventory. Periodic checks also help recover from missed automatic updates.

The storefront then shows whether each size is available.

The implementation does not automatically publish every product that appears in MoySklad. It only updates items that have been deliberately prepared and linked. This prevents an incomplete internal record from becoming a public product page without review.

The We Nera team has been especially positive about two parts of the result: the visual presentation of the website and the fact that stock availability updates without forcing the customer-facing catalog to mirror MoySklad.

That is a paraphrase of client feedback, not a measured performance result.

Why product variants matter more than product counts

A catalog of 114 products did not mean 114 stock values.

At launch in May 2026, those products contained 309 size variants.

A customer sees one dress page with several sizes. The inventory system sees separate sellable variants. If a size M is sold while size L remains available, the website must update the correct variant rather than hiding the entire product or showing every size as available.

This makes identifier quality essential.

Each storefront variant needs a stable relationship with the corresponding inventory record. A product title is not enough because titles can change, be translated or be rewritten for customers. The relationship should rely on identifiers that remain stable when the merchandising content changes.

This separation gives the brand freedom to improve the product page without breaking the inventory link.

Why images should not automatically come from MoySklad

Inventory systems and online stores often need different image strategies.

An internal system may prioritize speed and operational convenience. Some records may have no image. Others may use compressed files or basic references that are enough for staff to identify the item.

A fashion storefront has a higher visual burden. Customers need consistent, detailed photography that communicates material, shape, styling and brand identity.

For We Nera, the product image library was therefore managed separately from MoySklad.

This allowed Magaz to:

• use customer-ready photography;
• keep image quality consistent across product pages;
• edit and prepare images without changing the inventory record;
• publish visual collections and editorial content;
• avoid treating an operational image field as the final storefront asset.

The correct choice depends on the retailer. If the images inside MoySklad are already complete, consistent and optimized for the web, synchronizing them may be efficient. If they are not, copying them only transfers the problem to the website.

Why website navigation should not copy warehouse groups

Internal product grouping is usually designed for the people who operate the business.

Customer-facing navigation has a different purpose. It should reduce the time between arrival and finding a relevant product.

A fashion customer may browse by:

• product type;
• current season;
• occasion;
• collection;
• collaboration;
• editorial selection;
• campaign.

Those navigation paths can exist only on the website while every product remains linked to its MoySklad variant for stock.

On We Nera, customer-facing navigation includes standard product categories alongside collections and editorial groupings such as Bride’s Farewell and Stylist’s Edit.

This is not decoration. It is merchandising.

MoySklad does not need to become the place where every seasonal campaign is maintained. The storefront does not need to inherit the warehouse grouping. The two systems only need a reliable link at the product and variant level.

What happens when a new collection arrives?

As of July 2026, We Nera introduces new collections approximately once a month.

A new collection is not only an inventory update. It combines operational and customer-facing work.

The workflow is:

1. The collection is photographed.
2. The brand shares the final product material with Magaz.
3. The customer-facing products are prepared with images, titles, descriptions, translations, prices, variants and collection placement.
4. Once the corresponding products and variants are available in MoySklad, Magaz links or synchronizes them with the prepared storefront records.
5. Stock availability begins updating from MoySklad.
6. The products and collection go live.

When the necessary MoySklad records already exist, connecting the prepared products requires only a small number of implementation steps. The important part is that the workflow is repeatable.

The brand does not need to start a new website project every month. It repeats a defined catalog and inventory process.

How stock updates work without exposing internal implementation

A retailer does not need to understand API endpoints or webhook infrastructure to evaluate the result. It does need to know what causes an update and which system wins when data conflicts.

For We Nera:

• MoySklad is the authoritative inventory source for linked products;
• stock-changing activity in MoySklad triggers a refreshed stock check;
• a scheduled check provides a safety net;
• Magaz writes the current absolute availability for the matched variants;
• unlinked MoySklad products are not automatically published;
• customer-facing content in Magaz is not overwritten by internal MoySklad content.

This is a one-way stock synchronization from MoySklad to Magaz.

Magaz does not push a WhatsApp order back into MoySklad in this implementation. That means the merchant records the completed sale through its operational process, and MoySklad then becomes the source for the next authoritative inventory update.

This trade-off is relevant because a WhatsApp order is not necessarily a paid order.

Should a WhatsApp order reserve stock automatically?

Not always.

In the We Nera flow, the customer:

1. chooses the exact product and size;
2. adds products to the basket;
3. provides contact and delivery details;
4. sends the structured order to the store through WhatsApp;
5. receives confirmation and a QR code for payment.

The order received by the store can include the selected products, variants, quantities, customer information, total and a link to the prepared cart.

However, the WhatsApp submission does not automatically reserve the items in MoySklad.

The reason is commercial, not technical. A customer may send an order and never complete the QR payment. Automatically reserving every unconfirmed chat order could remove stock from sale even when no purchase occurs.

This setup also has a limitation: until the completed sale is recorded in MoySklad, the inventory system does not yet know that the item has been sold through that conversation.

A retailer that needs immediate reservation should use a different workflow. Tilda’s official MoySklad integration, for example, can create orders in MoySklad and configure reservation and stock write-off rules. A custom Magaz implementation can also be scoped around a different order or payment flow when required.

The right question is not whether automatic reservation is good or bad. It is when the retailer considers an order real.

The order artifact

A structured messaging order should not force the seller to restart the conversation.

A store can receive an order in a format like this:

New order

Customer: Anna S.

Phone: +7 …

Delivery: Almaty

Product: Alexandra Crop Cape

Colour: Milk

Size: M

Quantity: 1

Total: 100,000 KZT

Cart: saved order link

The seller can confirm current availability, send the payment QR code and arrange delivery.

The customer still completes the transaction through WhatsApp, but the product selection has already happened in the store.

The cost of a MoySklad integration is not only the connector

There is no useful universal price for connecting an inventory system to an online store. Cost depends on what is synchronized, how clean the source data is, whether orders must travel back, how variants are structured and who maintains the catalog after launch.

A realistic cost comparison should include:

• storefront setup and design;
• product and variant mapping;
• cleanup of identifiers or duplicated records;
• catalog preparation;
• image preparation and storage;
• titles, descriptions and translations;
• category and collection structure;
• stock, price, order and reservation rules;
• testing across sales channels;
• monitoring and recovery when an integration stops delivering updates;
• onboarding every new collection;
• future changes when the retailer’s process changes.

A standard connector can be inexpensive when its assumptions match the business.

A connector becomes more expensive when staff repeatedly work around it, when a developer must be called for each change, or when the website inherits incomplete product data that later has to be repaired manually.

The lowest setup cost is not necessarily the lowest operating cost. The useful comparison is the cost of keeping the store accurate and usable over time.

How done-for-you implementation works

A managed implementation is not the same as purchasing access to software.

For a MoySklad-connected store, Magaz can take responsibility for:

1. understanding which system should own each type of data;
2. reviewing product and variant identifiers;
3. preparing the customer-facing catalog;
4. deciding which MoySklad records should link to which storefront products;
5. implementing and testing the synchronization;
6. configuring the ordering or payment flow;
7. publishing the initial catalog;
8. maintaining the workflow when new collections arrive;
9. changing the integration when the retailer’s operations change.

The merchant still provides the commercial decisions, product information, photography and operational access required for the project.

The difference is ownership of the final result. The retailer does not need to separately coordinate a storefront builder, catalog team, integration developer and ongoing operator.

Who should choose what?

The best option depends on who will build, maintain and own the store and its connection to MoySklad.

Choose Tilda when its standard integration fits and you want to build the storefront yourself

Tilda has an official MoySklad integration. According to Tilda and MoySklad documentation current in July 2026, it can synchronize prices and stock, transfer website orders to MoySklad, configure warehouses and reserve products from orders.

That is a strong fit when:

• the standard CommerceML workflow matches the business;
• the team is comfortable building the site, preparing product cards, uploading new collections and keeping the synchronization running;
• the catalog can be managed inside Tilda or synchronized from MoySklad;
• the retailer does not need a separate partner to own catalog preparation and ongoing implementation.

In a Magaz implementation this work is included. The difference is not the feature list. It is who sets everything up and maintains it: the retailer’s team or a partner.

Tilda may be the simpler answer for a retailer that needs a conventional DIY website with a supported connector.

Choose Shopify when you want its global commerce ecosystem and can own the integration

Shopify supports ERP integration through apps, integration platforms and custom APIs. Its B2B documentation notes that custom API integrations provide the most flexibility but require more resources and recommends technical assistance for setup and launch.

Shopify can be the better choice when:

• the business wants a standard online checkout and the wider Shopify ecosystem;
• an internal team or implementation partner can own the project;
• regional payment, inventory and operational integrations have been confirmed;
• the retailer is prepared to maintain the architecture as systems change.

It is not the wrong platform because an implementation stalled. It simply does not remove the need for someone to own the implementation.

Choose a link-in-bio with a built-in store when the assortment is small and stable

A link-in-bio service is no longer just a page of links. Taplink, for example, documents a store mode with product cards, collections, catalog search, product variants with up to three options, a cart and online payment.

According to Taplink’s store documentation current in July 2026, it does not describe per-variant stock tracking or a native MoySklad integration. When the same assortment is sold through several channels, availability has to be updated by hand.

That makes a link-in-bio store a reasonable choice when the assortment is small and stable and the owner can keep it current manually. It stops fitting when size-level availability must stay accurate on its own, which is the problem this article is about.

Choose custom development when the retailer wants to own a bespoke system

Custom development is appropriate when the business has unique workflows, wants full architectural control and has the team or budget to maintain the system.

The important question is not whether a developer can build the integration. It is who will own changes, monitoring, catalog operations and future collections after the first delivery.

Choose Magaz when you need the implementation owned for you

Magaz is likely to fit when:

• MoySklad should remain the inventory source;
• the storefront should not copy the internal catalog;
• the retailer needs customer-facing titles, descriptions, translations and merchandising;
• product photography should be managed separately;
• variants must be matched and maintained;
• the business sells through Instagram, WhatsApp, physical retail or several channels;
• a standard connector does not reflect the desired order flow;
• new collections arrive regularly;
• the retailer wants one partner to own the storefront, catalog and integration.

Magaz is not the right choice when a standard connector already solves the requirement and the retailer is comfortable operating the store internally.

It is also not a marketplace and does not provide marketplace traffic or logistics.

Live example

We Nera is the live storefront described in this article.

The public store shows:

• Russian and English;
• KZT, KGS and EUR;
• product-type navigation;
• collections and editorial groupings;
• product pages with selectable variants;
• a basket and structured order flow;
• a storefront powered by Magaz.

The internal inventory relationship is intentionally less visible. Customers see the presentation and current availability they need, not the structure of the operational system behind it.

About Magaz

Magaz is a managed ecommerce implementation partner for retailers in Central Asia and nearby markets.

It combines storefront software with catalog preparation, image work, multilingual content, ordering and payment flows, and integrations with systems such as MoySklad, 1C, POS services and other operational tools.

WhatsApp and Telegram ordering are supported flows, not the technical limit of the platform. Magaz can also implement online payments and custom integrations when the retailer’s market and workflow require them.

The clearest fit is a retailer that wants its own branded sales channel but does not want to coordinate the storefront, catalog and technical implementation separately.

Evidence and limitations

The We Nera figures in this article come from Magaz project records for the store’s launch in May 2026:

• one client store;
• 114 products;
• 309 size variants;
• one MoySklad warehouse;
• Russian and English;
• KZT, KGS and EUR.

The monthly collection cadence was confirmed by Magaz in July 2026.

Technical descriptions are intentionally limited to the information a retailer needs to evaluate the workflow. Internal endpoints, source code, error-handling rules and infrastructure details are not included.

Sources

• We Nera live online store
• MoySklad official website
• MoySklad documentation for its Tilda integration
• Tilda documentation for MoySklad synchronization
• Shopify B2B documentation for integrating external ERP and business systems
• Taplink documentation for adding store products
• Taplink documentation for store configuration
• Magaz

FAQ

Should an online store copy every product field from MoySklad?

No. MoySklad can remain the source of truth for stock while the online store manages customer-facing titles, descriptions, images, translations, categories and seasonal collections separately. Copying everything is useful only when the operational catalog is already suitable for customers.

What should usually be synchronized from MoySklad to an online store?

The answer depends on the retailer, but stock and variant identifiers are often the most important data. Prices, orders, reservations and product content can also be synchronized when the business wants those systems to share responsibility for them.

Can MoySklad update stock for individual sizes?

Yes, when each size or other product variant is correctly represented and linked between the systems. In the We Nera implementation, 114 products contained 309 size variants at launch in May 2026, and availability was matched at variant level.

Do product images need to come from MoySklad?

No. An online store can use a separate library of high-quality product photography while MoySklad supplies stock data. This is often a better fit for fashion, jewellery and other brands where visual presentation is part of the product experience.

Can website categories be different from MoySklad groups?

Yes. The website can organize products by customer-facing product types, seasonal collections, campaigns or curated edits even when those groupings do not exist in MoySklad. The inventory identifiers can stay linked without forcing both systems to use the same navigation.

Does a WhatsApp order automatically reserve stock in MoySklad?

Not in every implementation. For We Nera, submitting an order to WhatsApp does not immediately reserve stock because the customer has not necessarily completed payment. A retailer that needs automatic order creation and reservation should use a workflow configured for that requirement.

Is Tilda enough for a MoySklad online store?

It can be, if the retailer is ready to do the work itself. Tilda has an official MoySklad integration that can exchange orders, prices and stock, and it can reserve items from website orders. But the retailer's team still builds the site, prepares every product card, uploads new collections and keeps the synchronization configured on its own. In a Magaz implementation all of that is included: the Magaz team sets up and maintains the storefront, the catalog, the variant mapping and the synchronization.

When is Magaz a better fit for a MoySklad integration?

Magaz is a stronger fit when the retailer wants one partner to implement the storefront, map product variants, define what should synchronize, prepare customer-facing content and maintain the workflow as collections change. It is not necessary when a standard connector and an internally managed catalog already solve the problem.