Order state sync

Once Mirakl orders are imported, you handle them from Shopware just like any other order: pick, pack, ship, refuse, accept. Order state sync translates those Shopware state changes back into the right Mirakl action, so the operator and the buyer always see the same status you see.

How it fires

There’s nothing manual to click in the Mirakl module — the sync is driven by the Shopware order state machine.

1. Open the Shopware order from the regular Orders list, or from the Imported Orders list (Dashboard → Quick Start → Orders).
2. Change the state as you normally would (order state, delivery state or payment state, depending on what your Reverse status mapping says).
3. The plugin picks up the transition, looks up the linked Mirakl order, and sends the matching action to the operator.
4. After the operator confirms, the Mirakl Status column on Imported Orders is refreshed so Shopware and Mirakl show the same status.

Which Shopware state triggers which Mirakl action

You configure that per connection in the Reverse status mapping editor — open it from Mirakl → Settings → Connections → row context menu → Reverse Status Mapping, or from step 10 of the setup wizard. The editor has three sections — Order state, Delivery state, Transaction state — each listing every Shopware state with a dropdown next to it.

Each Shopware state can be mapped to one of:

• — — no action (the default; leave most rows on this).
• Accept (OR21) — accept the order on Mirakl.
• Ship (OR24) — mark the order as shipped on Mirakl.
• Set tracking info - without shipment confirmation (OR23) — push tracking metadata to Mirakl without yet marking the order as shipped.
• Refuse (OR29) — refuse / reject the order lines.

Sensible defaults are pre-filled, but you can override them per connection — handy if you sell on several operators with different workflows (auto-accept vs manual-accept).

Typical setup:

Mirakl action	Typical Shopware trigger
Accept (OR21)	Order state → In progress
Set tracking info - without shipment confirmation (OR23)	Delivery → Shipped (partially) with tracking data
Ship (OR24)	Delivery → Shipped
Refuse (OR29)	Order state → Cancelled

Refusing an order

When you trigger the refuse action, the plugin tells the operator that every line of the order has been declined. The current implementation does not include a refusal reason code or comment — only the per-line “not accepted” flag. If your operator requires a reason code, do the refusal manually in the operator panel instead.

Sending tracking info

If your Shopware state transition carries tracking metadata (carrier and tracking number), the plugin first sends a tracking update, then the ship action. If you re-trigger the same transition later with the same tracking data, the tracking update is skipped (only the ship action runs); if the tracking data changed (you reshipped with a different carrier), a fresh tracking update is sent.

Why duplicate triggers are safe

Before each call the plugin checks the order’s current Mirakl status:

• Ship / tracking are skipped if the order is already shipped, received or closed.
• Refuse is skipped if the order is already refused or cancelled.
• Accept is only allowed when the order is still waiting for acceptance.

So if the background worker delivers the same transition twice (which can happen on retries), no harm is done — the second call is recognised as a no-op.

Refresh after action

After every successful state call, the plugin re-fetches the order from Mirakl to read back the actual post-action status. This is more reliable than guessing from the API response — you always see what the operator actually decided to do with the request.

Manual refresh

If the Mirakl status looks out of date (for example the operator changed it on their side), the Order refresh action pulls fresh data for a single order.

Tips & gotchas

Tip

The Reverse status mapping is per connection. If you sell on several operators with different workflows, configure each connection independently from Mirakl → Settings → Connections → row context menu → Reverse Status Mapping.

Caution

If the operator rate-limits a state call, the plugin re-tries it after the operator’s requested wait time. Other transitions in the same batch continue normally — only the throttled one waits.

Note

Order state sync only fires for Shopware orders that come from Mirakl. Orders you created manually in Shopware are ignored — they’re not Mirakl orders, so there’s nothing to push.

Caution

If you map one Mirakl action to several Shopware transitions, every matching transition fires the action — including ones you didn’t mean. Be conservative: only map the transitions that really should push to Mirakl.

Related

• Order import — how the orders got into Shopware in the first place
• Order refresh — refresh a single order on demand
• Reason codes — reference data pulled from the operator
• API throttling — how the plugin respects operator rate limits