Autodoc Integration – Feature & Process Guide

Autodoc is a Germany-based, multi-country marketplace for car parts and accessories, built on the Mirakl marketplace platform — the same platform behind our La Redoute integration. As a standard Mirakl implementation, most of the integration follows familiar Mirakl behaviour, with a set of Autodoc-specific rules layered on top: vehicle/fitment data on products, its own courier list, and a strict "New condition only" rule.

This page describes what the Autodoc 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 Autodoc as products first, then offers (price/stock/availability) second — an offer can't go live until its product exists on Autodoc. Both steps happen automatically once a product is ready; there's no manual per-product action needed from the seller.

• Category-specific attributes: every product is checked against its Autodoc category's required/optional attribute set before it's sent. A product missing a category-required attribute is the most common reason a product fails to reach Autodoc.
• Vehicle/fitment data (car-parts specific): depending on category, a product can carry a "universal fit" flag for trucks/cars/motorcycles, TecDoc/K-type vehicle compatibility codes, a free-form compatible-vehicle list, whether the fitment is TecDoc-sourced, and an OEM/manufacturer cross-reference list. This is what sets Autodoc apart from a general-goods Mirakl marketplace like La Redoute.
• Images: a main image is required (meeting Autodoc's size requirement) plus up to 5 secondary images; listing-level images take priority over product-level ones.
• Brand: the brand set at listing level takes priority over the product's own brand; a brand Autodoc doesn't already recognise has to be requested from their marketplace team before it can be used.
• Variants: products are grouped into a variant set by linking each one to the same parent product. Each variant is still created as its own product record, and siblings don't need to be submitted together. A product can be detached from its variant group later by resending it without that parent link.
• Units: weight is stored internally in grams and converted to kilograms for Autodoc.

Updating products

Product content, price and stock can each be refreshed independently after a product is live:

• Content updates (title, description, images, attributes, vehicle/fitment data) are resent through the same import mechanism used to create the product in the first place.
• Price-only updates and stock-only updates each run as their own lightweight flow.
• Full updates (content, price and stock together) are split into two separate batches — one for items with price protection off, one for items with it on — because Autodoc's system rejects a batch that mixes priced and price-less rows.
• Protect Price / Protect Quantity / Protect whole item flags work as on our other Mirakl integrations: the protected field (or the whole item) is left out of whatever update is being sent, so it's never overwritten on Autodoc.

Deactivating / removing products

Autodoc supports two distinct ways to take a listing down:

• Zero-stock update: sets the offer's stock to zero without removing it. The listing stays in place, off-sale, and can be brought back by pushing a positive stock update later.
• Offer delete: removes the offer entirely. The product is then marked as taken down internally and can be re-listed later by creating a fresh offer against the same product.
• A "Closed" account-level flag stops all new product creation and most other updates, but still allows the zero-stock and delete actions through — so a listing can always be pulled down even when the integration is otherwise closed.

Pricing & Stock Sync

• RRP-based discounting: if an RRP is set and it's higher than the current price, Autodoc automatically shows the item as discounted (RRP as the "was" price), and a discount date window is generated. If no discount dates are set, the window defaults to two years from today. When RRP is not higher than price, no discount is sent.
• Condition: only "New" condition items are accepted by Autodoc; any other condition value is rejected.
• Stock: stock updates keep quantity in sync while an offer is active, and are also the mechanism used to bring an item back on-sale after a zero-stock deactivation.
• Protect flags: Protect Price and Protect Quantity (see Product Management above) apply equally here — a protected field is simply left out of the update sent to Autodoc.

Order Management

Getting orders

Orders are pulled from Autodoc automatically and continuously — the same process both picks up new orders and refreshes the status and details of orders already stored in Pentagon Connect, so there's no separate "check for updates" step. When an account first connects, Pentagon Connect looks back 90 days for existing orders; after that it checks for anything changed since the last run. An order can also land in Pentagon Connect already accepted, already shipping, or already shipped (for example after a resync), so status isn't assumed to always progress in a straight line.

New orders are accepted automatically by default. If a specific order line has been internally flagged for rejection, that line is sent back to Autodoc as rejected rather than accepted; everything else is accepted as a matter of course.

Order information we store

For every order, Pentagon Connect stores:

• Marketplace order ID, order status, currency, created date, delivery-by date
• Buyer email and buyer ID
• Payment method, order subtotal, order total, discount amount/type, marketplace fee, total fee
• Billing address: name, phone number, company name, country, state, street (2 lines), city, postal code
• Shipping address: name, phone number, country, state, street (2 lines), city, postal code
• Carrier, tracking number, tracking URL, shipping service label
• Per line item: SKU, product title, item price, quantity, line status, shipping cost, VAT amount/percentage
• 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: Incomplete, Pending, Ready for Shipping, Shipped, or Cancelled — several distinct Autodoc statuses (e.g. both "Refused" and "Refunded") collapse into Cancelled on our side. Status moves in one direction only: once an order is Shipped it can only move to Cancelled, and Cancelled is final. An order carrying an open "incident" on Autodoc's side isn't currently reflected as a distinct status in Pentagon Connect — see Claims / incidents below.

Shipping orders

Once an order is accepted and ready, Pentagon Connect pushes the carrier and tracking details to Autodoc and marks the order shipped as one linked pair of actions.

• Carrier matching: the carrier on the order is matched against Autodoc's own registered carrier list (see Carriers Supported below); 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 as a generic fallback.
• Partial shipment is not supported — Autodoc always expects the full order shipped in a single call, even if it physically ships in multiple parcels.
• If Autodoc already shows an order as shipped before Pentagon Connect's own shipment call goes through (for example, shipped from Autodoc's own back office), this is treated as a success rather than an error.

Cancellations

Which cancellation action applies depends on the order's own status flags — whether it can still be cancelled, and whether it's already been charged:

• An order that hasn't been charged yet can be cancelled in full.
• An order that has already been charged is cancelled at the line level instead, so specific items can be cancelled rather than the whole order.
• Only full-order cancellation is available for a not-yet-charged order — a partial cancellation isn't sent for those.

See Return & Refund Reason Codes below for the cancellation reasons available.

Refunds & returns

Refunds can be full or partial (by quantity or amount), and can cover the product, the shipping charge, or both, at the line-item level. Autodoc doesn't have a separate "return" object — a customer return is handled as a refund using the "Item returned" reason.

• Each refund line is sent to Autodoc as its own individual request; bundling multiple refund lines into one batch isn't safe, because Autodoc fails the entire batch if even one line in it fails.
• If some lines succeed and others fail, the refund is marked "Partially Completed" so partial success is still reflected accurately rather than shown as a flat failure.
• A default refund reason and a default cancellation reason can be configured, and are used automatically whenever no specific reason is supplied with a request.

Claims / incidents

Autodoc's Mirakl platform has its own "incident" concept (an order can carry an open incident status), which can delay seller payment even before a formal refund or cancellation is raised. This isn't currently mapped to a Pentagon Connect status or workflow, so an order with an open incident on Autodoc's side may not be visibly flagged as such in Pentagon Connect today — see Known Limitations.

Carriers Supported

Carriers aren't a fixed list Pentagon Connect maintains — they're whichever couriers Autodoc has registered on their side, read live from Autodoc. A carrier used on an order 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" fallback so tracking information isn't lost, though not every Mirakl marketplace is guaranteed to accept that fallback. Example couriers referenced in Autodoc's own documentation include DHL, DPD, FedEx, TNT and UPS, but the authoritative, current list is always whatever is registered on the account at the time.

Return & Refund Reason Codes

Reason codes are read from Autodoc/Mirakl for reference, but the working list used in Pentagon Connect's refund screen is maintained internally. Because our own reason list can't otherwise distinguish a refund reason from a cancellation reason, each one is labelled with its type when shown in the UI.

Refund reasons:

• 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
• Debit failed
• Debit timed out

A default reason (one per type) is used automatically whenever a refund or cancellation is requested without a specific reason supplied.

Known Limitations

• No partial shipments — every order ships to Autodoc as one complete shipment, even when it physically goes out in multiple parcels.
• Only "New" condition is accepted for offers — any other condition value is rejected outright.
• Offer SKUs are capped at 40 characters and cannot contain a "/".
• Full product/offer updates must be split into two separate batches (with vs without price) depending on the Protect Price flag — Autodoc rejects a batch that mixes the two.
• Refund and cancellation requests are all-or-nothing per batch, which is why each refund/cancellation line is sent individually rather than bundled together.
• The "Other" carrier fallback isn't guaranteed to work on every Mirakl marketplace, even though Pentagon Connect sends it as a standard fallback when no courier mapping or default carrier is set.
• Vehicle-variant/variation-group handling was still an open item in the source documentation at the time this guide was written — variants are linked purely by a parent-product reference, with no dedicated "group" object.
• Autodoc's "incident" order status has no defined handling in Pentagon Connect yet — this is a known, acknowledged gap rather than an oversight, and incidents can delay seller payment even before a refund or cancellation is formally raised.
• Orders and offers sync on a polling schedule, not instantly — a status change on Autodoc's side can take a short while to appear in Pentagon Connect.

Source Materials

This guide was built from Autodoc's Mirakl integration specification documents covering account setup, taxonomy, product and offer creation and updates, order retrieval and acceptance, shipment, and refunds/cancellations.