Debenhams Integration – Feature & Process Guide

Debenhams is one of the Mirakl-based marketplaces connected to Pentagon Connect. Products are sent to Debenhams in two steps — the product itself is created first, and only once it exists on Debenhams is an offer (price and stock) created for it — with a small number of Debenhams-specific rules layered on top, such as millimetre-based dimensions and its own main image, swatch and secondary image requirements.

This page describes what the Debenhams 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

New products are sent to Debenhams as products first; an offer can't be created until the product already exists on Debenhams. Both steps happen automatically once a product is ready — there's no manual per-product action needed from the seller. Every submission is checked against Debenhams' category taxonomy first, and a product missing a required attribute for its category will fail to send.

• Required fields: category, SKU, EAN (barcode), brand, title, description, colour, colour group, gender, a main image, and a swatch (thumbnail) image. A returns statement is also required, but if none is set Pentagon Connect falls back to a default value of "standard".
• Recommended fields: up to 11 secondary images; fabrication type is optional but recommended where relevant.
• Image sizing: the main image must be 1500px high × 1000px wide; the swatch image must be 120 × 120px.
• Optional fields: ethics statement, sustainability detail, pre-loved flag and condition rating, country of origin, customs (HS) code, item dimensions and weight, and a customisation group — none of these have a fallback value if left blank.
• Dimensions: Debenhams expects item length/width/height in millimetres. Where a more specific value has been set for the listing it's used as-is (assumed already correct); otherwise Pentagon Connect converts the product's dimensions from centimetres to millimetres automatically.
• Variants: products can be grouped into variant sets (e.g. size/colour of the same item) by setting a shared Variation Group on the product account. Each variant is still created as its own product record and doesn't need to be submitted together with its siblings — only a shared reference ties them into the same group. Removing that shared reference on a later update takes the product out of the group. If a Variation Group is set but no variant-level attributes are provided, the product is rejected as an error.
• Attribute conflicts: where the same attribute is available at both the general listing level and the variant level, the variant-level value is always used.

Updating products

Content updates (title, description, images, attributes) are sent through the same product import mechanism used for creation — the product file is re-submitted, and the same category/taxonomy validation runs again on every update. A product with a missing or invalid required attribute will fail the same way an initial creation would, and the error is captured and made available for the seller to review. Price and stock are updated independently through their own dedicated flows — see Pricing & Stock Sync below.

Deactivating / removing products

Two separate mechanisms are available:

• Marking a product "Closed" stops it from being sent to Debenhams for creation, and stops nearly all other updates going out for it — the one documented exception is that a zero-stock push can still be sent for a closed product, so it can be pulled off sale even after being closed.
• A dedicated "remove offer" action takes a live listing down from Debenhams entirely. Once it completes, the product is marked as removed and the listing goes inactive on Debenhams.

Pricing & Stock Sync

• Creating an offer: once a product exists on Debenhams, its price, stock and condition are sent as an offer. Only "New" condition is accepted — any other condition value is rejected as an error.
• RRP-based discounting: if an RRP is set and it's higher than the current price, Debenhams 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. This same logic applies to price-only updates, full offer updates, and offer creation alike.
• Price-only updates run as their own lightweight flow, for cases where only the price needs refreshing, without resending the rest of the offer.
• Stock-only updates run as their own flow too, and work both to update stock on a live listing and to bring a previously zeroed-out listing back with positive stock.
• Zero-stock updates are a distinct flow from a regular stock update — setting stock to zero this way also takes the listing inactive on Debenhams once it completes.
• Full offer updates (content, price and stock together) are split into two variants behind the scenes depending on whether the item's price is protected, so that a price-protected item's update never includes a price value at all, rather than sending a price that shouldn't be touched.
• Protect Price — when set, that item's price is left out of updates sent to Debenhams, so its live price is never overwritten.
• Protect Quantity — when set, stock is left out of updates (including full updates), so the quantity live on Debenhams isn't touched.
• Protect the whole item — when set, the item is skipped entirely for that update cycle, including price updates.
• Closed — stops all offer updates to Debenhams for that item.

Order Management

Getting orders

Orders are pulled from Debenhams automatically and continuously, with existing orders kept in sync as their status and details change (accepted, paid, shipped, refunded, etc.). The first run covers the last 90 days; after that, new and changed orders are picked up on an ongoing basis with no manual import step required.

Order lines are accepted automatically by default once they arrive in a "waiting acceptance" state. A line can be flagged internally for rejection before acceptance is sent, and any line that's already been cancelled or refunded on Debenhams is left out of acceptance automatically.

Order information we store

For every order, Pentagon Connect stores:

• Marketplace order ID, order status, order currency, created date, paid date, and delivery-by date
• Buyer email (marketplace-anonymised) and buyer/customer ID
• Payment method, order subtotal (excluding shipping), order total, shipping cost, discount amount/type, and total marketplace fee/commission
• Billing address: name, phone number, company name, country name and code, state, street (2 lines), city, postal code
• Shipping address: name, phone number, company name, country name and code, state, street (2 lines), city, postal code
• Carrier/courier name, shipping cost, shipping service label, tracking number, and tracking URL
• Per line item: SKU, product title, item price, quantity, line status, per-line shipping cost, and any refund or cancellation history for that line (amount and reason)
• 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
• Payment and refund transaction references, stored against the order for reconciliation

Order status is tracked in Pentagon Connect as one of: Incomplete, Pending, Ready for Shipping, Shipped, or Cancelled. Underneath that, each order line also carries its own more detailed status (e.g. awaiting acceptance, shipping, shipped, received, cancelled, refunded, or incident open) so that a partial action on one line — a single-line cancellation or refund, for example — can be tracked without moving the whole order.

Shipping orders

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

• Carrier matching: the carrier on the order is matched against Debenhams' registered carrier list (see Carriers Supported below) through an internal 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 fallback so tracking information isn't lost.
• Partial shipment is not supported — Debenhams 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 Debenhams.
• If Debenhams already shows the order as shipped by the time Pentagon Connect's own shipping update reaches it, Pentagon Connect still records the order as shipped on our side rather than treating this as a failure.

Cancellations

Whether an order is cancelled, and which of two cancellation routes is used, is driven automatically by flags Debenhams sets on the order — sellers don't need to work out which route applies:

• An order that hasn't yet been charged to the customer ("not yet debited") can only be cancelled in full — a partial cancellation of an uncharged order isn't allowed.
• An order that has already been charged is cancelled at the order-line level, the same way a refund is.

A reason is required for every cancellation — see Return & Refund Reason Codes below.

Refunds & returns

Refunds are requested per order line and can be full or partial (by quantity or amount), covering the product, the shipping charge, or both. Pentagon Connect validates that a line isn't refunded for more than remains available on it. A customer return is handled as a refund using an "item returned" reason rather than as a separate return object.

When a refund or cancellation request covers several order lines, each line's outcome is tracked individually — if some lines succeed and others fail, the request is recorded as partially completed, with the specific failed lines and their error kept for review, rather than the whole request being treated as one pass/fail unit.

If no reason is supplied with a refund or cancellation, Pentagon Connect can fall back to a default reason configured for the account (set separately for refunds and for cancellations).

Claims / incidents

Debenhams' Mirakl order data includes an "incident" concept: the customer or Debenhams can open one on an order line once the order reaches shipping, shipped, or received status. If the order hasn't been paid yet when an incident is raised, we don't get paid for it. Unlike the rest of the order-management flow, exactly how Pentagon Connect represents and tracks an open incident internally is not fully documented in the current source material — this is a genuine documentation gap rather than a confirmed statement that incidents aren't handled.

Carriers Supported

Carriers aren't a fixed list we maintain — they're whichever couriers Debenhams has registered on their side, which Pentagon Connect reads live from Debenhams. A carrier used on an order is matched against that live list via an internal carrier-mapping table, or an account-level default carrier if no mapping matches; if neither applies, the carrier name and tracking number are still sent through under a generic "Other" carrier so tracking information isn't lost. Illustrative carriers seen in Debenhams' Mirakl environment include FedEx, UPS, DHL, DPD and TNT, though the live list read from Debenhams at send time is what's actually used.

Return & Refund Reason Codes

Refund reasons (as read from Debenhams' own back office):

• No response from the shop
• Out of stock
• Cancelled by the client prior to shipping
• Item returned
• Item not received on delivery
• Agreement found with the seller
• Item not received on return
• Faulty item – no return required
• Faulty item
• Item unable to be shipped

Cancellation reasons:

• Cancelled by the client prior to shipping
• Cancelled due to late shipment (system-generated)
• Debit failed (system-generated)
• Debit timed out (system-generated)

If a refund or cancellation is requested without a specific reason, Pentagon Connect can apply a default reason for the account — configured separately for refunds and for cancellations.

Known Limitations

• No partial shipment — every order ships to Debenhams as one complete shipment.
• Only "New" condition is accepted for offers; any other condition is rejected.
• Uncharged orders can only be cancelled in full — a partial cancellation isn't possible before the customer has been charged.
• Full offer updates are split into two variants (with price / without price) behind the scenes depending on whether price is protected — a quirk of the underlying file format rather than something sellers need to act on.
• Claims/incidents handling isn't fully documented — the concept exists on Debenhams' side, but Pentagon Connect's internal tracking of an open incident isn't confirmed in the current source material.
• Variant-level attributes silently win over general ones when the same attribute is set in both places — worth knowing when troubleshooting an unexpected value on a variant.
• A Variation Group with no variant-level attributes is a hard error — an easy case to misdiagnose as a mapping bug when it's actually missing data.
• Dimension units require conversion. Product dimensions are converted from centimetres to millimetres when falling back to generic product fields; a listing-level value is trusted as-is, so a mismatch there could push the wrong unit through.
• Returns statement defaults to "standard" if none is set on the product.

Source Materials

This guide was built from Debenhams' Mirakl integration specification documents covering authentication and rate limits, taxonomy, product and offer creation and updates, order retrieval and acceptance, shipment, and refunds and cancellations.