Offer (Mirakl)

A Mirakl catalog has two layers: products and offers.

• Product: the master record for the item itself. Identifiers such as GTIN or JAN, the category in the operator's taxonomy, required attributes, title, description and images. It stays the same whichever seller sells it
• Offer: the selling terms a seller attaches to a product. Price, quantity, condition (new, used), lead time, shipping terms, the seller's own SKU, discount price and period, and whether the offer is active
• Linking: an offer attaches to an existing product through the product identifier (GTIN or JAN) or the marketplace product ID. Depending on the operator's settings, offers may only be accepted on approved products
• API: products go through the product import (P41) and offers through the offer import (OF01), as separate APIs

Buyers see one product page, with each seller's offer listed beneath it, ordered by price and shipping terms. "One product, many offers" is the basic shape of a marketplace.

Products and offers are separated so that catalog quality control and price competition can be handled independently. The operator reviews and governs product data to prevent duplicates and missing attributes. Price and stock are left to each seller and change often. If both lived in one record, a single seller's price change would become an update to the whole product page and touch every other seller's data.

In integrations, the difference in update frequency is what matters. Product data is cleaned up once at catalog registration and rarely changes afterwards. Stock and price move several times a day. Integration layers therefore usually treat product sync and offer sync as separate processes, with their own retry and rate-limit handling.

The other question is how to map offers onto systems that have no such concept. Shopify's data model has products and variants but no offers. How multiple Mirakl offers appear in Shopify, as variants, as metafields or as separate products, is a design decision for any store that becomes a marketplace. On the order management system (OMS) side, too, the first step is deciding how a marketplace "offer" maps onto the OMS's own product and stock-and-price records.

Our Connector for Mirakl separates product sync, stock sync, price sync and order sync into distinct flows. The split follows Mirakl's two-layer model, so that fast-moving stock and price data can flow independently of product data. On the seller's order management system, a Mirakl marketplace is treated as one more sales channel: the OMS product master maps to Mirakl products, and stock and price map to offers. Because the attributes accepted by the product import differ from one marketplace to the next, attribute mapping is configured per operator.

In Shopify, price is part of the product object, so the offer concept clicked the first time we met it: Mirakl assumes that several sellers list the same product, and in that case the price differs per seller too.