Decathlon Integration – Feature & Process Guide

Decathlon's marketplace runs on the Mirakl platform, connecting third-party sellers into Decathlon's own storefronts across multiple European countries. Pentagon Connect integrates with Decathlon as a standard Mirakl seller connection, handling product and offer creation, price and stock synchronisation, and the full order lifecycle from acceptance through to shipping, cancellations, refunds and claims.

This page describes what the Decathlon integration supports — which product, pricing, order and refund actions are available, what data we capture, and what isn't currently supported.

Quick Reference

Product Management

Pricing & Stock

Orders & Fulfilment

Refunds, Returns, Cancellations & Claims

Product Management

Creating products

Products are sent to Decathlon as products first, then as offers — an offer can't go live until its product already exists on Decathlon. Both steps happen automatically once a product is ready; there's no manual per-product action needed from the seller.

• Required fields: category, the seller's own SKU, a barcode (EAN or UPC), and a brand chosen from Decathlon's own fixed brand list rather than free text. A missing barcode or category blocks a product from being created at all.
• Recommended fields: a main title, and up to 5 images (1 main plus 4 secondary).
• Category-specific and locale-specific content: a long block of category-specific attributes is validated on top of the core fields, and content such as the title, tagline and description is tracked separately per country storefront the product is sold on (for example, the same content field becomes a different value per language-country combination such as English/Great Britain or Spanish/Spain). Only one category was present in the sample data, so it isn't possible to confirm from this material how attribute requirements vary across Decathlon's wider category tree — only that they do vary by category.
• Variants: products can be grouped into variant sets (e.g. size/colour of the same item) by linking each sibling product to a shared parent product reference. Each variant is still created as its own product record; you don't need to submit every sibling variant together. Removing a product from a variant set is done by resubmitting it for update without that parent reference.

Every submitted product is checked against its category's required attributes (downloaded from Decathlon's own taxonomy) before being sent; a product missing a category-required attribute is the most common reason a product fails to reach Decathlon, and the resulting error is reported back per SKU.

Updating products

Price, stock and full offer content (description, condition, dispatch lead time, per-country pricing, eco-tax, free-return flag) can each be updated after a product is live, and price/stock can be updated independently of the rest of the offer:

• Price-only and stock-only updates each run as their own lightweight flow, for cases where only that one value needs refreshing.
• Full offer updates are split into two separate feeds — one that includes price and one that excludes it — so that a price-protected product can still receive its other updates.
• Protect Price — when set on a product, price is left out of every update sent to Decathlon, so its price on the marketplace never gets overwritten.
• Protect Quantity — when set, stock is left out of updates, so the quantity live on Decathlon isn't touched.
• Protect the whole item — when set, only quantity updates are sent through; everything else is skipped for that update cycle.

No example of updating a product's core content (title, images, category, description) separately from an offer was present in the source material, so it isn't confirmed here.

Deactivating / removing products

Two distinct actions are available. Sending a zero-stock update takes an offer off sale immediately while keeping the listing itself in place — useful for a temporary pause. A separate "remove listing" action deletes the offer from Decathlon entirely. Marking a product "Closed" internally stops all further updates to Decathlon apart from that zero-stock update. There's no example in the source material of deleting the underlying product record itself, only its offer.

Pricing & Stock Sync

• RRP-based discounting: if an RRP is set and it's higher than the current price, Decathlon automatically shows the item as discounted (RRP as the "was" price). If no discount dates are set, the discount window defaults to two years from today.
• Low-stock alert: an optional per-offer threshold quantity that can trigger a stock alert once inventory drops below it.
• Per-country pricing: price (and its discount) can be overridden per individual Decathlon country storefront, alongside a list of which storefronts the offer is actively published on.
• Eco-tax / eco-contribution: an environmental producer-responsibility fee, reported per producer identifier and amount; it appears to apply only to certain categories.
• Free returns: a per-offer yes/no flag indicating the item qualifies for a free return.
• Shipping/logistic class: each offer carries a size and weight class (Small, Medium, Large, Oversize 1, Oversize 2, or Free Shipping) that drives its shipping template on Decathlon; it can be set as a default at account level and overridden per product.
• VAT: not confirmed for Decathlon specifically — there's no dedicated tax-rate field in the source material. A note on the price field suggests the price may already include tax, which is the standard Mirakl pattern seen elsewhere, but this hasn't been confirmed for Decathlon.

Order Management

Getting orders

Orders are pulled from Decathlon automatically and continuously: the first run looks back 90 days, and after that new and changed orders are picked up on a rolling basis. Existing orders already in Pentagon Connect have their status and details kept in sync as they progress — an order can also arrive already partway through its lifecycle (for example already shipped), and Pentagon Connect still fills in the missing shipment and status details correctly. No manual import step is required.

Decathlon can list a single product across up to 13 country storefronts (Belgium, Switzerland, Germany, Spain, France, Great Britain, Italy, Netherlands, Poland, Portugal, Romania, Hungary and the Czech Republic); each storefront is tracked as its own Pentagon Connect account, and every incoming order is matched to the correct account by its storefront. Mirakl doesn't support bundled products, so bundles are broken down using Pentagon Connect's standard internal logic.

Order information we store

For every order, Pentagon Connect stores:

• Marketplace order ID, order status, currency, created date, paid date, delivery-by date
• Buyer email (marketplace-anonymised) and buyer ID
• Payment method, order subtotal, order total, shipping cost, discount amount/type, marketplace fee
• Billing address: name, phone number, company, country, state, street (2 lines), city, postal code
• Shipping address: name, company, country, state, street (2 lines), city, postal code — a phone number specifically for the shipping contact was not confirmed as captured in the source material
• Carrier, shipping service label, tracking number, tracking URL, shipped date
• Per line item: SKU, product title, item price, quantity, line status, shipping cost, tax amount and rate
• Sales tax, marketplace VAT and internal VAT are tracked as three separate figures at both order and line level, so different tax views can be reconciled independently

Order status is tracked in Pentagon Connect as one of: Pending, Ready for Shipping, Shipped, or Cancelled (closed, refused, cancelled and fully refunded orders on Decathlon's side all map to Cancelled). An order line can also carry an open "Incident" flag independently of the order's main status — see Claims / incidents below.

Shipping orders

Once an order is accepted and ready, Pentagon Connect pushes the carrier and tracking details to Decathlon and marks the order shipped in a single automated step.

• Carrier matching: the carrier on the order shipment is matched against Decathlon's own registered carrier list using a dedicated carrier-mapping table; if there's no match, an account-level default carrier is used if one is set; if neither applies, the carrier name and tracking number are still sent through under a generic "Other" carrier so tracking information isn't lost.
• Partial shipment is not supported — Decathlon (via Mirakl) always ships the full order in a single shipment. Pentagon Connect can still record multiple internal shipments against an order, but only one, full shipment reaches Decathlon.

Cancellations

Which cancellation action is used depends on whether the order has already been paid (debited) by the customer:

• Orders not yet debited can only be cancelled in full — partial cancellation isn't offered before payment.
• Orders already debited can be cancelled per order line, including a partial quantity or amount.

Cancellation reasons include: cancelled by the client prior to shipping, unable to ship (out of stock), cancelled due to late shipment (system-initiated), and customer cancelled via seller. See Return & Refund Reason Codes below for the full list.

Refunds & returns

Refunds can be full or partial (by quantity or amount), and can cover the product price, the shipping charge, or both. They're requested per order line, with each refunded line submitted as its own request. Decathlon doesn't have a separate "return" object — a customer return is handled as a refund with the reason Item returned. The only validation applied is that a line can't be refunded for more than its remaining refundable amount.

When a refund or cancellation covers several order lines, it's only tracked as fully completed once every line succeeds; if some lines succeed and others fail, it's tracked as partially completed, with the failed lines' error kept separately so it can be investigated.

See Return & Refund Reason Codes below for the full refund reason list.

Claims / incidents

Decathlon's claims mechanism ("Incident") can be opened by the customer or by Decathlon once an order is shipping, shipped, or received. An incident is tracked per order line rather than as a whole-order status change. If an order isn't yet paid when an incident is raised, we don't get paid for it.

Incidents are opened and closed with their own reason codes, for example:

• Opening a claim: item not received, item not as ordered, defective item, right to retract the order, counterfeit item, delivery took longer than expected
• Closing a claim: item finally received, item fit the description after all, replacement item received, agreement made with the vendor, solution found by the operator, customer service handled by the vendor, no response from the customer

Carriers Supported

Carriers aren't a fixed list we maintain — they're whichever couriers Decathlon has registered on their side, which Pentagon Connect reads live from Decathlon (examples seen in the source material include FedEx, UPS and Evri, but the live list can differ by account). A carrier used on an order shipment is matched against that live list via our own carrier-mapping table, or an account-level default; if it doesn't match anything registered, the carrier name and tracking number are still sent through under a generic "Other" carrier so tracking information isn't lost.

Return & Refund Reason Codes

Refund reasons (as shown in Decathlon's own back office):

• No response from the shop
• Out of stock
• Cancelled by the client prior to shipping
• Item returned
• Item not received
• Agreement found with the vendor

Cancellation reasons:

• Cancelled by the client prior to shipping
• Unable to ship — out of stock
• Cancelled due to late shipment (system-initiated)
• Customer cancelled via seller

Known Limitations

• No partial shipment — every order ships to Decathlon as one complete shipment, even if it's picked and packed in several parts internally.
• Full cancellation only before payment — an order not yet debited from the customer can only be cancelled in full, not by line or partial quantity.
• No confirmed example of updating a product's core content (title, images, category, description) independently of its offer — only offer-level updates were documented in the source material.
• No confirmed example of deleting a product record itself, as opposed to removing or zeroing out its offer.
• VAT/tax handling on price is inferred, not confirmed — there's no dedicated tax-rate field in the source material.
• Only one category appeared in the sample data, so how required attributes vary across Decathlon's full category tree cannot be confirmed from this material — only that they do vary.
• Carrier list is dynamic, not a fixed set we can quote in advance — it depends on what Decathlon has registered for the account at the time.
• Shipping-address phone number is not confirmed as captured — only the billing contact's phone number is confirmed in the source material.

Source Materials

This guide was built from Decathlon's Mirakl integration specification documents covering authentication and account setup, taxonomy download, product and offer creation and update, price and stock synchronisation, listing deactivation and removal, and order management — getting orders, accepting orders, shipping, cancellations, refunds and claims.