Check Mirakl order status: Find open orders and incidents

Find open Mirakl orders by their order status: WAITING_ACCEPTANCE identifies orders awaiting acceptance, while SHIPPING identifies shipments that have yet to be confirmed. Check open incidents separately using has_incident, independently of this status selection. A useful worklist also needs the correct marketplace and shop, individual order lines and any available shipping deadlines.

With Backlane, you can check the data made available for these tasks through a Mirakl connection in an AI chat. Setup is covered in the Backlane documentation, and the basics in the practical guide to marketplace analysis. The following prompts are templates for read-only checks. They have not been run against a seller account.

Which Mirakl status calls for which check?

Start by distinguishing an order you can process from one waiting for a different process step. Mirakl maintains a status for the order and a separate status for each line. With partial cancellations or incidents, the overall status must not replace the status of the affected line.

Status or field	What it means for your check	Next step
WAITING_ACCEPTANCE	The acceptance decision is pending.	Check the affected lines and your actual ability to fulfil them.
WAITING_DEBIT / WAITING_DEBIT_PAYMENT	The order is waiting for a payment process step.	Check the status and payment workflow in the seller portal; do not schedule shipment solely because of the order’s age.
SHIPPING	The order is being prepared for shipment.	Compare open lines, any shipping deadline and warehouse or dispatch records.
SHIPPED	Shipment has been confirmed on the marketplace.	If there is a problem, check shipment and line details; the status alone does not prove delivery.
has_incident: true	At least one line in the order has an incident.	Identify the affected line and the reported reason.

The Mirakl Orders interface OR11 describes these separate fields. The documentation for acceptance decisions and shipment confirmations associates those steps with WAITING_ACCEPTANCE and SHIPPING. This guide reads the data; it does not perform those changes.

Other statuses, such as TO_COLLECT for a collection process, need a separate check where they apply to your operations. The table is a focused selection for acceptance, shipping and incidents. Payment workflows can also vary by operator or order: do not infer a general claim that payment has been received from SHIPPING alone.

How do you find the entire open workload?

First select the specific Mirakl connection and shop. Identical order numbers from different marketplaces must not be merged. Backlane provides access to the interfaces; the request establishes which ones your marketplace and permissions allow you to use.

To retrieve the complete open workload, do not set a lower date boundary such as “ordered since yesterday”. An order from last week may still be waiting for acceptance. A filter for recently updated orders is also unsuitable: it could exclude an order that has remained unchanged for a long time.

Results are paginated. Read every page and uniquely identify orders by their ID within the same connection and shop. Statuses can change during retrieval, so the list documents a retrieval with a start and end time, not an immutable historical snapshot. Mirakl documents the filters and pagination in OR11.

Check Mirakl connection [connection] and shop [shop] using read-only
access. Create separate lists for WAITING_ACCEPTANCE and SHIPPING
using order_state_codes. Set no lower boundary for creation or
update dates. Read all results pages while respecting request limits.
Within each connection and shop, count each order_id once and each
order_line_id within it once. Flag conflicting duplicate results.

Show the connection, shop, order_id and, for each line,
order_line_id, offer_sku and order_line_state. Add created_date,
last_updated_date and shipping_deadline where supplied.
Do not apply the order status to every line without checking.
Do not display names, addresses or contact details.

Sort SHIPPING by available shipping_deadline in ascending order.
List missing deadlines separately. Sort WAITING_ACCEPTANCE by
creation date without inferring an acceptance deadline from it.
State the source, retrieval start/end in Europe/Berlin, the number
of orders and lines, and completeness.
Flag errors and partial retrievals; do not change any data.

The prompt produces two operationally different lists. An order with three lines remains one order and three lines. Reporting these figures separately prevents a worklist from being mistaken for order statistics.

Which deadline is actually supported by the data?

shipping_deadline is the shipping deadline supplied by Mirakl. If present, you can compare it with the retrieval time. A deadline in the past on an order in SHIPPING is a reason to check actual dispatch and the confirmation sent to the marketplace. It does not by itself prove that the parcel is still in the warehouse.

created_date is the creation date. last_updated_date records the most recent change to the record. Without additional event data, neither tells you how long the order has been in its current status. Report a missing shipping deadline as missing; do not calculate one from a blanket default. The fields are defined in the OR11 response schema.

How do you find incidents on orders that have already shipped?

Run a second query with has_incident=true, without limiting it to the two open shipping statuses. Otherwise, incidents on orders that have already shipped, for example, would be excluded.

The order-level indicator does not identify the cause. Check order_line_state and any available reason codes and descriptions on the lines. If the response does not identify the affected line or the reason, that is precisely what needs checking next in the seller portal. Missing information is not permission to add a plausible cause.

Read all orders with has_incident=true in [Mirakl connection]
and [shop]. Do not use an order_state_codes filter or a lower
boundary for creation or update dates.
Read all pages while respecting request limits.

For each order, show its identifier, order status and the affected
lines where these are unambiguous. Show line status,
order_line_state_reason_code and order_line_state_reason_label
where available. Flag missing or uncertain matches.
Propose a next check for each case and clearly distinguish it
from the finding actually reported by the system.

State the source, retrieval period and completeness. Link duplicates
from the open-order list using connection, shop and order_id;
retain both reasons for checking. Do not display buyer data.
Do not send messages or change anything.

What does prioritisation look like in an example?

Suppose you check a shop on 30 October at 09:00, Europe/Berlin. All the following identifiers and values are fictional:

Example	Reported finding	Specific next check
EXAMPLE-A	SHIPPING, shipping deadline today at 08:00	First compare the dispatch evidence with the marketplace confirmation.
EXAMPLE-B	WAITING_ACCEPTANCE, created the previous day	Check the ability to fulfil the open lines before deciding whether to accept.
EXAMPLE-C	SHIPPED, has_incident: true, reason missing	Check the affected line and incident details in the seller portal.

For EXAMPLE-A, the data shows that a specific deadline has passed. For EXAMPLE-B, only the order’s age is known. EXAMPLE-C belongs on the worklist despite its shipped status. AI can summarise these differences; actual processing and a subsequent verification query remain separate steps.