Reference · built on requestConnectorCommerce & orders

Mirakl

Marketplace orders, shipments, returns, incidents, and offers from a Mirakl instance through the Seller and Operator REST APIs.

Request accessPricing ↗

About

Mirakl Platform is the marketplace and dropship software that retailers, the operators, run to sell third-party sellers' goods. Every operator has its own instance, such as your-instance.mirakl.net, with three API groups: Front APIs for storefront systems, Operator APIs for the operator's own systems, and Seller APIs for the sellers on that marketplace. Endpoints carry short codes: OR11 lists orders, RT11 lists returns, ST11 lists shipments.

Through Fibric, an operator watches orders in WAITING_ACCEPTANCE, incidents, and pending returns across each marketplace you sell on and proposes what to do next: accept order lines, post tracking, refund a line, or accept a return. You approve, the connector calls the endpoint once, and the record shows what changed and why.

This is a reference listing. It documents what Fibric would read from Mirakl and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Orders from OR11 (GET /api/orders) with order_state, shipping_deadline, has_incident, can_cancel, and customer details, filtered by start_update_date
  • Order states STAGING, WAITING_ACCEPTANCE, WAITING_DEBIT, WAITING_DEBIT_PAYMENT, SHIPPING, SHIPPED, TO_COLLECT, RECEIVED, CLOSED, REFUSED, CANCELED
  • Differential order exports from OR13 and OR14 for large volumes
  • Returns and items to return from RT11 (GET /api/returns) and RT12
  • Shipments and items to ship from ST11 (GET /api/shipments) and ST12
  • Customer and operator message threads from M11 (GET /api/inbox/threads), filtered by entity such as MMP_ORDER
  • Offers and stock from OF21 (GET /api/offers), and accounting documents and transaction lines from IV01 and TL02

Proposed actions

  • Target capability: propose accepting or refusing order lines in WAITING_ACCEPTANCE through OR21 (PUT /api/orders/{order_id}/accept)
  • Target capability: propose carrier tracking through OR23 (PUT /api/orders/{order_id}/tracking) and ship confirmation through OR24
  • Target capability: propose a refund on order lines through OR28 (PUT /api/orders/refund)
  • Target capability: propose accepting or refusing a return request through RT21 (PUT /api/returns/accept)
  • Target capability: propose resolving a line incident through OR64 (PUT /api/orders/{order_id}/lines/{line}/resolve_incident)

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Accept orders before the operator's deadline

    New orders sit in WAITING_ACCEPTANCE until the seller acts. The operator checks stock against each line and proposes OR21 accept or refuse decisions for your approval.

    With Order Risk, Promise Date

  • Post tracking and close the shipping loop

    For orders in SHIPPING with a label from your carrier system, the operator proposes OR23 with the carrier code and tracking number, then OR24 to confirm shipment.

    With Tracking Sync, Stalled Shipment

  • Work incidents and returns from one queue

    Orders with has_incident and returns from RT11 form one worklist. The operator drafts the reply, the refund line, or the RT21 decision and asks for approval.

    With Returns Triage, Delivery Dispute

  • Reconcile marketplace payouts

    Transaction lines from TL02 and accounting documents from IV01 are matched to the orders behind each billing cycle so the finance team sees what was paid out and why.

    With Payout Reconciliation

Requirements

  • A seller account on the operator's Mirakl instance, or operator access to your own instance
  • A shop API key whose user holds ROLE_SHOP_ADMIN or the ROLE_PARTNER_* roles each endpoint lists, such as ROLE_PARTNER_ORDER_READ and ROLE_PARTNER_ORDER_ACCEPT
  • The instance hostname, since every marketplace is a separate base URL
  • For order refunds, ROLE_PARTNER_ORDER_REFUND; for return decisions, ROLE_PARTNER_ORDER_RETURN_WRITE
Authentication
For the Seller APIs, a shop API key sent in the Authorization header; for the Operator APIs, OAuth 2.0 authorization code through auth.mirakl.net or an operator bearer token.

Limits

  • Mirakl publishes a call frequency per endpoint: OR11 asynchronous polling is capped at once per minute, or every 15 minutes for third-party integrations.
  • HTTP webhooks and Cloud Events are available to Operator users only, so a seller-side connector polls rather than subscribes.
  • OF24 requires every offer field on each call; fields left out are reset to their defaults. OR04 accepts at most 100 orders per call.
  • The OpenAPI files leave out multipart endpoints that take a file plus an object, and endpoints with dynamically built URLs.

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Mirakl ↗

Questions and answers

Does the Seller API send webhooks?
No. Mirakl documents HTTP Webhooks and Cloud Events for Operator users only. A seller integration polls OR11 with start_update_date, which Mirakl backdates by a delta so no order is missed, or runs the OR13 differential export.
What does a shop API key allow?
Each endpoint lists the roles it accepts. ROLE_SHOP_ADMIN covers nearly all of them; narrower ROLE_PARTNER_* roles such as ROLE_PARTNER_ORDER_READ, ROLE_PARTNER_ORDER_SHIP, or ROLE_PARTNER_OFFER_WRITE limit a key to one job.
How is one Mirakl marketplace different from another?
Each operator runs its own instance with its own hostname, channels, shipping zones, reasons, and custom fields. The connector reads those settings from endpoints such as CH11, SH11, RE01, and AF01 per instance rather than assuming them.
Ask about Mirakl

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Mirakl through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy