Das Problem in einem Absatz

Mirakl-betriebene Marktplätze (Shop-Apotheke, Douglas, Galaxus, Kaufland, Cdiscount, OTTO Market) senden Kundenfragen ins eigene Seller-Portal, nicht in dein Email-Postfach. Jeder Operator nutzt eine leicht andere Mirakl-API-Version. Jeder Marktplatz erzeugt eigene Bestellnummern (z.B. COM-237482229-2-A bei Shop-Apotheke). Dein PlentyOne kennt die Bestellung unter einer anderen ID. Dein Support-Team bekommt kontextlose Nachrichten aus 5 Portalen und muss zwischen PlentyOne, dem Mirakl-Seller-Portal und Versanddienstleistern hin- und herklicken, um eine einzige Antwort zusammenzubauen. Daher kommen 70% der WISMO-Personalkosten.

Die Architektur

Die saubere Pipeline sieht so aus:

Mirakl Seller API (read-only) — neue Threads vom Messaging- Endpoint des Operators ziehen (GET /api/messages). Jeder Operator hat einen eigenen Host (z.B. https://shopapo.mirakl.net, https://douglas2.mirakl.net).
PlentyOne REST API (read-only) — Bestellung über Marketplace-External-ID suchen (Plenty speichert Mirakl-COMs als External-Order-IDs).
Bridge-Layer — Mirakl-Thread-ID ↔ Mirakl-Order-COM ↔ Plenty-Order-ID ↔ Versand-Tracking-Nummer.
Classifier + Responder — ein LLM erkennt die Intent (WISMO, Beschwerde, Retoure, Rechnung, Produktfrage), sucht die Bestellung, formuliert die Antwort in der Kundensprache.
Antwort-Kanal — je nach Operator: Mirakl-Messaging- Endpoint-Reply, oder Fallback Direkt-Email wenn der Kunde an eine Shop-Adresse geschrieben hat.

Stolperfallen wenn du es selbst baust

Mirakl ignoriert manche Filter still. Beim Filtern von orders per externalOrderId wird teils trotzdem die volle Page zurückgegeben — du musst lokal nachfiltern.
Plenty-Order-Search per externalOrderId ist bei nicht-numerischen IDs unzuverlässig. Du brauchst einen Fallback der die lokalen Auftrags-Nummern scannt.
State-mutating GETs. Mirakl hat GET-Endpoints wie /messages/{id}/read oder /orders/{id}/validate die wie Reads aussehen, aber Status ändern. Wenn du naiv eine "lies alles"- Schleife baust, markierst du still Nachrichten als gelesen — der Mensch findet sie nie.
Identitäts-Verifikation. Marketplace-Bestelldaten sind sensibel (Adresse, Inhalt). Du musst sicherstellen, dass der Anfragende auch der Besteller ist, bevor du Tracking rausgibst — Phishing ist real.
Operator-spezifische Quirks. Shop-Apotheke nutzt Pharma-IDs, Douglas hat eine andere Thread-Form, Kaufland markiert Incidents. Jeder braucht einen kleinen Adapter.

Wie Paketwo das Ende-zu-Ende löst

Paketwo Bot ist eine SaaS, die genau das alles für dich verdrahtet. Die Integrationen sind technisch read-only — auf HTTP-Transport- Layer schlägt jeder POST/PUT/PATCH/DELETE gegen PlentyOne oder Mirakl einen Error bevor er das Netzwerk erreicht. State-mutating GET-Pfade sind über eine Path-Segment-Allowlist geblockt. Selbst ein Bug im Bot kann deinen Shop oder einen Marktplatz-Status nicht mutieren.

Der Matcher ist gegen Live-Mirakl-Operators gehärtet (Shop-Apotheke läuft bereits produktiv für mindestens einen Tenant). Für brand-neue Mirakl-Operators dauert die Anbindung 3 Tage — der pro-Operator-Adapter ist ein dünner Wrapper um den gemeinsamen Client.

Zwei Wege es einzuführen

Selbst — 14 Tage kostenlos starten, Plenty-REST-Credentials hinterlegen, dann Mirakl-API-Key pro Operator eintragen. ~20 Minuten pro Marktplatz.
Setup-Paket — 30 Minuten Screen-Sharing mit Vagabond Consulting, wir verdrahten Mirakl + Plenty, konfigurieren die Case-Policies und bestätigen die erste Auto-Reply. Die meisten Shops sind binnen 24h live. Anfrage über kontakt.

FAQ

Welche Mirakl-Operators sind unterstützt?

Produktiv: Shop-Apotheke, Douglas. Sandbox-getestet: Galaxus, Kaufland. Jeder andere Mirakl-Operator: 3 Tage Integrationszeit. Schick uns einfach die API-Base-URL des Operators + deinen Seller-Key.

Schreibt Paketwo nach Mirakl oder Plenty zurück?

Nein. Beide Integrationen sind technisch write-blocked. Die Antwort geht per Email (SMTP) oder über den expliziten Reply-Kanal — niemals über einen state-mutating Plenty- oder Mirakl-Call.

Was wenn ein Marktplatz-Kunde nach einem Plenty-internen Detail fragt?

Die Bridge mapped Marketplace-Order-IDs auf Plenty-interne IDs und stellt die Antwort aus beiden Seiten zusammen. Der Kunde sieht eine kohärente Antwort.

Ist das DSGVO-konform?

Ja. EU-Hosting (Deutschland), Postgres Row-Level-Security zwischen Tenants, verschlüsselte Per-Tenant-Credentials, Audit-Log mit SHA-256-Hash-Kette. AVV im Scale-Plan, auf Anfrage in allen Plänen.

Spar dir den Eigenbau, nutz die fertige Lösung.

14 Tage gratis, keine Kreditkarte. Heute live für Mirakl-Plenty-Shopify-Händler.

Kostenlos starten Setup-Paket buchen

Verwandte Glossar-Einträge: WISMO-Automation für PlentyOne · Shopify ↔ Mirakl ↔ Plenty Bridge · Zendesk vs. Paketwo

Mirakl ↔ PlentyOne Integrationfür einheitliche Kundenservice-Antworten