This page is the catalog of everything that crosses the boundary between your connector and the Mirakl Connect Channel Platform, grouped by the business domain it belongs to. For each domain, it lists the REST operations your connector calls and the events your connector receives, says what each one is for, and points to the guide that implements it.
The directory answers what exists and what it means. It does not cover how to call an operation, or how the events reach you. Those mechanics are the same across every domain, and they are documented once:
- Calling the APIs: the base path, the
channel_idparameter, the authentication, and how synchronous and asynchronous operations differ. - Receiving events: the event envelope, the destination you receive the events on, and how to configure it.
Every event is either a fact or a command, and the difference decides what you must do:
- A fact notifies you that something has happened, such as an updated product, or a change to an offer's price or stock. You react if you need to, and you owe nothing back.
- A command asks your connector to perform an action, and it expects you to report the outcome through a REST call.
Both arrive as ordinary events, with the same envelope. The type of the event tells you which one it is.
One table for each domain lists everything it carries. The Type column says whether the entry is an operation you call, or an event you receive.
A store is a seller's storefront within your channel. This domain brings a seller's stores into Mirakl Connect, keeps their business information current, and tells your connector when a seller links or unlinks a store.
sellerAccountStoreCreate and sellerAccountStoreUpdate belong to the Account Channel Platform. upsertBusinessInformation belongs to the Channel Platform.
| Reference | Type | Purpose |
|---|---|---|
| sellerAccountStoreCreate | API | Create the seller's channel stores, and link them to a Mirakl seller account. |
| sellerAccountStoreUpdate | API | Update a store's information. |
| upsertBusinessInformation | API | Publish a store's business details, which is what makes the store usable in Mirakl Connect. |
| StoreManagementFeatureEvent | Event | Reports the status of one store-level feature, named by feature. Most importantly, the store-linking feature tells you whether the seller has linked the store (linked) or unlinked it (unlinked), which activates or deactivates its synchronization flows. |
Implement it: Stores.
This domain covers two things:
- The channel's catalog setup: the offer attributes and the offer use cases it supports, and the taxonomy that products are classified into.
- The flow that keeps the products, the offers, the prices, and the stock synchronized to the channel.
| Reference | Type | Purpose |
|---|---|---|
| configureChannelCatalog | API | Declare the channel's catalog capabilities, which are its offer attributes and the offer use cases it supports. The supported use cases are what allow Mirakl Connect to emit offer upserts at all. |
| upsertProductType | API | Register a product type, which is the category a product belongs to and the attributes it must carry. It is a prerequisite for product creation. |
| createTaxonomyRule | API | Create a taxonomy rule that redefines a product type's attributes for a specific case. |
| updateStoreCatalogItems | API | Report the integration status and the diagnostics of each offer and of each product back to Mirakl Connect. The statuses you report decide what it sends next. |
| ProductUpsertEvent | Event | A product was created or updated, and it must exist on the channel. |
| OfferUpsertEvent | Event | An offer was created or updated, and it must be published to the channel. |
| PriceStockUpsertEvent | Event | An offer's price or stock changed. The price and the stock travel together on this one event, not on separate events. |
Implement it: Catalog configuration, Taxonomy, and Catalog flow. Step-by-step guides cover how to create or update products, create and update offers, sync price and stock, and report feedback.
This domain covers the whole life of an order placed on your channel, together with the returns opened against it, the documents attached to it, and the carriers that ship it. Your connector works in two directions at once here:
- It pushes the channel's orders and returns into Mirakl Connect.
- It carries out the actions Mirakl Connect asks for.
| Reference | Type | Purpose |
|---|---|---|
| upsertOrders | API | Synchronize the orders into Mirakl Connect, with their lines, their statuses, and their adjustments. |
| updateActionStatus | API | Report the outcome of an action Mirakl Connect requested, against the action_id of that action. |
| updateAnonymizeAfterDate | API | Set the date after which Mirakl Connect can anonymize each order's personal data. |
| upsertReturns | API | Synchronize the returns into Mirakl Connect. Each return names the order and the order lines it was opened against. |
| uploadOrderDocument | API | Attach a document to an order or to one of its returns, such as a return label, a customer invoice, or a delivery slip. |
| deleteOrderDocument | API | Remove a document you uploaded before, naming both the order and the document. |
| upsertCarriers | API | Share the list of carriers the channel allows, so that a shipment can name a carrier the channel supports. |
| OrderActionEvent | Event | Requests an action on an order or on one of its returns. It carries an action_id to report the outcome against. |
Every order command and return command arrives on that one event, and there is no other event for them. The type field of its envelope says which action Mirakl Connect requests, and it selects the shape of the data payload.
Dispatch on type. There is no separate event type for these actions. The payload schema named in the last column is the shape of data for that type, not an event you can subscribe to.
type | Applies to | Payload schema |
|---|---|---|
ACCEPT | order | OrderAcceptanceCommandEvent |
CREATE_SHIPMENT | order | OrderShipmentCommandEvent |
CANCEL | order | OrderCancelationCommandEvent |
REFUND | order | OrderRefundCommandEvent |
ACCEPT_RETURN | return | ReturnAcceptanceCommandEvent |
UPDATE_RETURN_TRACKING_INFORMATION | return | ReturnTrackingInformationUpdateCommandEvent |
ACKNOWLEDGE_RETURN_RECEPTION | return | AcknowledgeReturnReceptionCommandEvent |
CLOSE_RETURN | return | CloseReturnCommandEvent |
UPLOAD_DOCUMENT | order or return | DocumentUploadCommandEvent |
Report the outcome of every one of these actions with updateActionStatus, on the action_id of the event. A command is not complete until you have confirmed it.
Implement it: Orders and Returns. Step-by-step guides cover how to sync orders into Connect and how to handle order action events.
- Integration overview: where your connector sits, the two directions, and the delivery guarantees that these operations and events obey.
- Business use cases: the flows these operations and events belong to, and where to start.
- Calling the APIs and Receiving events: the mechanics behind every entry on this page.
- Data model: the definition, field by field, of the entities these operations and events carry.
- Best practices: the rules on idempotency, ordering, retries, and errors that they all obey.
- REST APIs reference and Event APIs reference: the complete schemas of the requests, the responses, and the payloads.