Skroutz Eshop integration: catalogue, stock and orders

Connecting an Eshop to Skroutz involves several separate processes: product catalogue delivery, price and stock updates, order intake and status management. A dependable implementation needs stable product identifiers and an agreed owner for each field. Publishing a catalogue alone does not establish an automated order workflow or a reliable connection to the business ERP.

The XML feed handles the complete catalogue. The Products API updates availability, price and quantity; it does not create new products. We establish stable identifiers and validate variants, images and availability before publication. An ERP SKU change needs an explicit mapping decision, otherwise a connector may treat the same commercial item as an unrelated product and lose the link to its existing offer.

Orders API calls and webhooks serve the order workflow. A webhook can arrive again, so the external order identifier is stored before a local order is created. Acknowledging an incoming event should be separated from processing it inside the ERP. Operators need to distinguish received, imported and pending orders, with enough information to act when an intermediate step fails.

Downloading a courier voucher is not proof that a parcel is prepared. Shops enrolled in the mandatory Set as Ready programme need an explicit readiness action. We connect that action to packing completion rather than a file download. Cancellations and returns also require separate inventory rules, particularly when an order has already reserved stock or a returned item still awaits inspection.

Consider a retailer with five units of an item, selling through a physical store, an Eshop and Skroutz. The ERP owns commercial stock and the connector publishes the sellable quantity after reservations. An incoming order is imported once, labelled with its channel and included in subsequent availability calculations. If the ERP is temporarily slow, the order remains in a visible processing queue instead of disappearing. This is an implementation example, not a claim about a named customer or a promised synchronization speed.

Acceptance testing includes duplicate events, price changes, exhausted inventory and cancellation of an already reserved order. An ERP outage must not silently lose an accepted order. Monitoring should show the last successful update and discrepancies by SKU. Starting with a selected product group gives staff an opportunity to validate operating rules before the full catalogue is connected. Support responsibilities should be clear when the marketplace, ERP or connector rejects a request.