Für Entwickler

Geprüftgeprüft 2026-09-20

Kurz gesagt

MitoOps hat eine öffentliche Schnittstelle in drei Formen über derselben normalisierten Datenschicht. Sie unterscheiden sich darin, wer fragt und was er darf:

Form	Richtung	Was sie darf
REST-API (`/api/v1`)	Ihr Programm fragt	nur lesen: beantwortet ausschließlich `GET`, keine Operation ändert etwas
MCP (`/api/mcp`)	eine KI-Anwendung fragt	liest dieselben Daten und hat zusätzlich eng begrenzte Schreibzugriffe hinter sensiblen Berechtigungsbereichen, die ein Mensch ausdrücklich erteilt: `automations:write` (ein deaktivierter Automatisierungsentwurf und eine Revision einer laufenden Automatisierung, die ein Mensch veröffentlicht), `coupons:write` und `coupons:delete` (ein Rabattgutschein mit Vorschau und Bestätigung), `affiliate:write` (Verwaltung des Partnerprogramms: Partnerkonto, Portaltexte, Vorlagen, Kampagnen, Dokumentrichtlinie), `affiliate:approve` (Entscheidung über eine einzelne, benannte Provision; Auszahlungen bleiben in der Anwendung), `availabilities:draft` (ein Änderungsvorschlag für die Verfügbarkeitsliste, der erst in den Shop gelangt, wenn ein Mensch ihn in der Anwendung freigibt) und `claims-settings:draft` (ein Änderungsvorschlag für die Reklamationseinstellungen, der erst geschrieben wird, wenn ein Mensch ihn in der Anwendung freigibt). Außerdem `claims-routes:draft`, `product-content:draft` und `category-content:draft`: ein Vorschlag für den Rücktransport bei Reklamationen und für Produkt- und Kategorietexte, den ein Mensch in der Anwendung freigibt, oder der sofort geschrieben wird, wenn der Kunde für den Bereich bewusst das autonome Schreiben einschaltet. Sonst wird über MCP nichts angelegt oder geändert
Ausgehende Webhooks	MitoOps sendet an Sie	eine signierte Nachricht über ein Ereignis (Bestellung, Zahlung, Sendung, Lager, Rechnung, Reklamation) an Ihren Endpoint

Die Schnittstelle stellt derzeit 130 MCP-Werkzeuge bereit (102 zum Lesen, 28 zum Schreiben hinter sensiblen Berechtigungen: Entwurf und Revision einer Automatisierung, Rabattgutscheine, Verwaltung des Partnerprogramms sowie Änderungsvorschläge zu Verfügbarkeiten, Reklamationseinstellungen und Rückversand sowie zu Produkt- und Kategorietexten, die erst ein Mensch durch Freigabe in der App übernimmt, sofern der Kunde für den Bereich nicht bewusst das autonome Schreiben einschaltet), 101 REST-Endpunkte (alle nur lesend) und 32 Berechtigungsumfänge, davon 13 sensible, über 19 Datenbereiche. Die Zahlen entstehen beim Erstellen dieser Seite aus dem Katalog der App und werden nicht von Hand geschrieben.

Was Sie über REST und MCP lesen können: Shops, Bestellungen, Produkte und Kategorien, Lagerbestand mit Bewegungsverlauf, Rechnungen und Gutschriften, Sendungen und Zustellstatistik, Besucherzahlen und Kanäle, Finanzberichte und Verkäufe, das Kundenverzeichnis und die Kundenanalyse in Pseudonymen, Lieferanten, Reklamationen mit Statistik, das Partnerprogramm, Automatisierungen, die Verfügbarkeitslisten der Shops, Webhook-Endpoints und den Tarif des Kontos mit seinen Limits.

Über MCP können Sie nicht eine Bestellung oder ihren Status ändern, ebenso wenig Lagerbestände, ein Produkt oder die Verfügbarkeit, die ein Produkt hat, oder einen Preis; Sie können keinen Beleg ausstellen, keine Erstattung vornehmen, keine Webhook-Endpoints verwalten, keine Automatisierung aktivieren, keine Provisionen gesammelt freigeben und keinen Partner auszahlen. Jeder Schreibzugriff liegt hinter einem eigenen sensiblen Berechtigungsbereich: ein deaktivierter Automatisierungsentwurf (aktivieren kann ihn nur ein Mensch in der Anwendung), ein Rabattgutschein (Vorschau und Bestätigung), die Verwaltung des Partnerprogramms, die Entscheidung über eine einzelne, benannte Provision und ein Änderungsvorschlag für die Verfügbarkeitsliste (in den Shop schreibt ihn ein Mensch, indem er ihn in der Anwendung freigibt). REST hat überhaupt keine schreibenden Aufrufe. Zugangsdaten zu Versanddienstleistern, zum Shop oder zur Analytik lassen sich auf keinem Weg lesen.

REST: nur lesen

Die Adresse ist /api/v1 auf der Domain Ihrer Anwendung. Aufrufe, Parameter, Antwortform, Zeiträume und Paginierung sind in der REST-Schnittstelle beschrieben. Die maschinenlesbare Beschreibung liegt unter /api/v1/openapi.json hinter demselben Schlüssel; ein angemeldeter Mensch kann sie auch aus der Ansicht Einstellungen → API & MCP öffnen. Die Beschreibung entsteht aus derselben Quelle wie die Schnittstelle und kann daher nicht von ihr abweichen.

Alles außer GET erhält 405, noch bevor der Server den Schlüssel überhaupt ansieht. Das ist keine vorübergehende Einschränkung: REST v1 hat keine schreibenden Aufrufe, und die Schreibzugriffe von MCP wurden bewusst nicht aufgenommen. Einen Änderungsvorschlag für Verfügbarkeiten können Sie über REST nur lesen (seinen Status); anlegen lässt er sich dort nicht.

MCP: Lesen und eng begrenzte Schreibzugriffe

Die Adresse ist /api/mcp. MitoOps ist ein standardmäßiger Remote-MCP-Server (Model Context Protocol, ein offenes, herstellerunabhängiges Protokoll); verbinden kann sich jede Anwendung, die Remote-MCP über HTTP mit OAuth oder mit einem Zugriffsschlüssel unterstützt. Claude.ai ist ein im Produktivbetrieb geprüfter Client; die genauen Schritte stehen in der MCP-Schnittstelle.

MCP-Tools bauen auf denselben Fähigkeiten auf wie REST: Es ist keine zweite Schnittstelle mit eigenen Abfragen. Die Liste der Tools richtet sich nach den Berechtigungsbereichen des Schlüssels oder der Einwilligung: Ein Tool außerhalb des Berechtigungsbereichs existiert für die Anwendung nicht. Jedes Tool trägt Annotationen gemäß der Protokollrevision 2026-07-28 (readOnlyHint, destructiveHint, idempotentHint), sodass die KI-Anwendung weiß, ob es sich um einen Lese- oder einen Schreibzugriff handelt.

OAuth: Verbindung im Namen eines Menschen

Eine KI-Anwendung, die Remote-MCP mit OAuth unterstützt, verbindet sich nicht mit einem Schlüssel. Sie geben ihr die Adresse /api/mcp, die Anwendung schickt Sie zur Anmeldung bei MitoOps (einschließlich des zweiten Faktors), und auf dem Einwilligungsbildschirm wählen Sie aus, was sie lesen darf, welche Shops betroffen sind und welche Schreibzugriffe sie vornehmen darf (Automatisierungsentwürfe, Gutscheine, Verwaltung des Partnerprogramms, Entscheidungen über Provisionen, Änderungsvorschläge für Verfügbarkeiten). Ihr Passwort sieht die Anwendung nie.

Was übergeben wird, entscheidet der angemeldete Mensch, und nie mehr, als er selbst sehen darf. Wer kein Recht auf Einkaufspreise hat, kann es nicht weitergeben; wer Automatisierungen nicht bearbeiten darf, sieht den Berechtigungsbereich automations:write auf dem Einwilligungsbildschirm gar nicht. Eine OAuth-Einwilligung verbraucht keinen Zugriffsschlüssel aus dem Limit des Tarifs, erfordert aber einen Tarif mit API & MCP: Ohne ihn öffnet sich der Einwilligungsbildschirm nicht und nennt den Grund.

Die Einwilligung lässt sich jederzeit unter Einstellungen → API & MCP widerrufen, und alle daraus entstandenen Zugriffe enden im selben Moment.

Zugriffsschlüssel

Für einen Server, der einen Server aufruft, oder für Ihr eigenes Programm:

Öffnen Sie in der Anwendung Einstellungen → API & MCP und klicken Sie auf Neuer Schlüssel.
Geben Sie einen Namen ein, an dem Sie den Schlüssel später erkennen.
Wählen Sie Berechtigungsbereiche, Shops und Schnittstellen (REST, MCP oder beide).
Wählen Sie die Gültigkeit und erstellen Sie den Schlüssel.

Der Schlüssel wird in einem Header übertragen; in der URL wird er bewusst nicht angenommen (URLs landen in Logs und im Browserverlauf):

Authorization: Bearer <Ihr Schlüssel>

Berechtigungsbereiche

Ein Schlüssel oder eine Einwilligung sieht nie mehr, als ihm oder ihr erteilt wurde. Die Tabelle wird aus dem Katalog der Anwendung abgeleitet:

Berechtigungsumfang	Zugriff	Sensibel	Was er freigibt
`stores:read`	lesen	nein	die Liste der Shops mit ihrem Code
`orders:read`	lesen	nein	Bestellungen einschließlich Positionen; Adresse nur als Land und Ort, Beträge nur mit `reports:read`
`products:read`	lesen	nein	Produkte, Kategorien und den Verkaufspreis aus der Produktkarte
`invoices:read`	lesen	nein	Rechnungen mit Positionen, Gutschriften und Proformarechnungen
`shipping:read`	lesen	nein	Sendungen, Sendungsverfolgungsereignisse, Versanddienstleister (ohne Zugangsdaten) und Zustellstatistik
`analytics:read`	lesen	nein	Besucherzahlen, Kanäle, Suchergebnisse und die Abdeckung der Bestellungen durch das Tracking
`search-console:read`	lesen	nein	Leistung in der Google-Suche aus dem synchronisierten Archiv: Tage, Suchanfragen, Seiten, Länder und Geräte
`inventory:read`	lesen	nein	Lagerbestände und den Verlauf der Lagerbewegungen
`reports:read`	lesen	sensibel	Umsatz im Vergleich und nach Monaten, Werbung (Ausgaben, Budget, ROAS, Werbekostenanteil, CPA, MER), wann Bestellungen eingehen, Umsatzquellen; Finanzübersicht eines Zeitraums (Umsatz, MwSt., Kosten, Ergebnis), Verkäufe je Produkt, Leistung je Bestellung, Kunden als Pseudonyme und Beträge in der Sammelliste der Bestellungen
`purchasing:read`	lesen	sensibel	Lieferanten, ihre Angebote und Kostenbestandteile
`claims:read`	lesen	nein	Reklamationen und Retouren mit Verknüpfungen zu Bestellung, Gutschrift und Rücksendung, Zeitachse und versendete E-Mails des Falls; Statistik und Prozesse des Moduls
`automations:read`	lesen	nein	den Katalog der Auslöser und Aktionen, die Liste der Automatisierungen, ihre Einstellungen, den Verlauf der Ausführungen und die Prüfung von Entwürfen
`automations:write`	schreiben	sensibel	Anlegen oder Bearbeiten eines deaktivierten Automatisierungsentwurfs und Vorschlag einer Änderung an einer aktivierten Automatisierung (Revision); einen Entwurf aktivieren oder eine Revision veröffentlichen kann nur ein Mensch in der Anwendung, die laufende Automatisierung ändert sich nicht
`webhooks:read`	lesen	nein	den Ereigniskatalog, Endpoints ohne Secret und das Zustellungsprotokoll ohne Inhalte
`account:read`	lesen	nein	den Tarif, aktivierte Funktionen und Limits mit aktueller Nutzung
`affiliate:read`	lesen	nein	das Partnerprogramm: Übersicht, Partner, Kampagnen, Rabattcodes, Conversions, Auszahlungen, Statistik, Einstellungen, Dokumente, öffentliches Portal, E-Mail-Vorlagen, Hilfeartikel und Code-Anfragen; Kontaktdaten der Partner nur mit `personal-data:read`, Bank- und Steuerdaten nie
`affiliate:write`	schreiben	sensibel	Verwaltung des Partnerprogramms: Entscheidung über ein Partnerkonto (freigeben, ablehnen, sperren), Bearbeitung von Code-Anfragen, nicht finanzielle Programmeinstellungen, Portaltexte, Hilfeartikel, E-Mail-Vorlagen, Kampagnen und Dokumentrichtlinie; die Entscheidung über Provisionen hat einen eigenen Berechtigungsbereich, Auszahlungen bleiben in der Anwendung
`affiliate:approve`	schreiben	sensibel	Entscheidung über eine Provision des Partnerprogramms nach Conversion-ID: freigeben, ablehnen oder stornieren (Ablehnung und Stornierung mit Grund, der Partner erhält eine E-Mail); eine ausgezahlte Provision wird nie zurückgesetzt, Sammelfreigabe und Auszahlungen gibt es von außen nicht
`customers:read`	lesen	nein	das Kundenverzeichnis: Pseudonym, Shops, Land, Sprache, Anzahlen und Daten über die gesamte Kundenbeziehung; Name, Firma, E-Mail und Telefon nur mit `personal-data:read`, Umsatz und LTV nur mit `reports:read`
`coupons:read`	lesen	nein	die Rabattgutscheine des Shops mit Rabatthöhe und Gültigkeit, die Unterstützung durch die Plattform, den Aktivierungslink und seine Bereitschaft
`coupons:write`	schreiben	sensibel	Anlegen eines Gutscheins in ausgewählten Shops (ein vorhandener mit anderen Parametern wird ohne ausdrückliche Zustimmung nicht überschrieben)
`coupons:delete`	schreiben	sensibel	unwiderrufliches Löschen eines Gutscheins im ausgewählten Shop nach einer Vorschau und ausdrücklicher Bestätigung; ein Gutschein mit einer aktiven Abhängigkeit (AI Mailing, Anmeldefenster, geplante Kampagne, Partner) wird nicht gelöscht
`chatbot:read`	lesen	nein	Statistik des Web-Chatbots für einen Zeitraum: Anzeigen und Klicks der Sprechblase (Klickrate), Chat-Öffnungen einschließlich ihres Auslösers, Anzahl der Unterhaltungen und Nachrichten, Ergebnisse, Kundenbewertungen, der Trichter der Newsletter-Anmeldung und eine deterministische Auswertung der Gesprächsthemen (Anteile, Produkte, Kandidaten für Wissenslücken); nur Summen
`chatbot-conversations:read`	lesen	sensibel	Unterhaltungen von Kunden mit dem Web-Chatbot: eine Liste mit der ersten Frage und Transkripte mit den Quellen der Bot-Antworten; der Kunde ist nur ein zufälliger Schlüssel der Unterhaltung, E-Mail, Telefon und IBAN im Text nur mit `personal-data:read`, sonst durch einen Platzhalter ersetzt; nur innerhalb der Aufbewahrungsfrist des Shops
`availabilities:draft`	schreiben	sensibel	ein Änderungsvorschlag für die Verfügbarkeitsliste des Shops (anlegen, bearbeiten, löschen) mit Vorschau; in den Shop gelangt er erst, wenn ein Mensch mit der passenden Berechtigung ihn in der Anwendung freigibt, sonst läuft er nach 24 Stunden ab; er ändert weder, welche Verfügbarkeit ein Produkt hat, noch den Lagerbestand
`claims-settings:read`	lesen	nein	E-Mail- und Dokumentvorlagen der Reklamationen, Moduleinstellungen, Tags, Rückversand und das Formular im Shop; ohne Zugriffstokens
`claims-settings:draft`	schreiben	sensibel	ein Änderungsvorschlag für Reklamationsprozesse, Status, Tags und Vorlagentexte mit Vorschau; geschrieben wird er erst, wenn ein Mensch mit der passenden Berechtigung ihn in der Anwendung freigibt, sonst läuft er nach 72 Stunden ab; gelöscht wird nichts
`claims-routes:draft`	schreiben	sensibel	ein Vorschlag, eine Rückversandroute anzulegen, zu ändern, ein- oder auszuschalten, geprüft wie auf dem Bildschirm; geschrieben wird er durch Freigabe in der App oder sofort, wenn der Kunde für den Bereich bewusst das autonome Schreiben eingeschaltet hat; löscht nie eine Route
`product-content:read`	lesen	nein	Beschreibung, Kurzbeschreibung und SEO-Texte eines Produkts direkt aus dem Shop, mit Hash und Schreibbarkeit jedes Feldes
`product-content:draft`	schreiben	sensibel	vorgeschlagene neue Produkttexte (bis zu 30 auf einmal), nur Inhaltsfelder, nie Preis, Bestand, Code oder EAN; geschrieben durch Freigabe oder sofort bei bewusst eingeschaltetem autonomem Schreiben
`category-content:read`	lesen	nein	obere und untere Beschreibung sowie SEO-Texte einer Kategorie, mit Hash und Schreibbarkeit je nach Shop-Plattform
`category-content:draft`	schreiben	sensibel	vorgeschlagene neue Kategorietexte (bis zu 30 auf einmal), nur Felder, die die Shop-Plattform schreiben kann; geschrieben durch Freigabe oder sofort bei bewusst eingeschaltetem autonomem Schreiben

Sensible Berechtigungsbereiche sind weder beim Ausstellen eines Schlüssels noch auf dem Einwilligungsbildschirm vorausgewählt: Ein Mensch muss sie bewusst anhaken. purchase-prices:read und personal-data:read haben kein eigenes Tool; sie entscheiden über Felder in den Antworten der anderen. Ein fehlendes Feld ist nicht null, es fehlt.

Berechtigungsbereiche sind eine öffentliche Zusage: Sie ändern sich nur abwärtskompatibel, und ein früher ausgestellter Berechtigungsnachweis erbt einen neuen Berechtigungsbereich nicht (die Berechtigungsbereiche sind darin namentlich eingetragen). Deshalb erhielten ein älterer Schlüssel und eine ältere Einwilligung keine personenbezogenen Daten, als diese am 2. 9. 2026 einen eigenen Berechtigungsbereich bekamen, und sie erhalten auch das Schreiben von Entwürfen nicht: Dafür braucht es eine neue Einwilligung oder einen neuen Schlüssel.

Einem bestehenden Schlüssel lässt sich ein neuer Bereich auch ohne Austausch des Schlüssels hinzufügen: Einstellungen → API & MCP → Bereiche bearbeiten. Der Schlüsselwert bleibt gleich, die Integration, die ihn nutzt, läuft weiter und erhält den neuen Bereich ab der nächsten Anfrage. Die Änderung nimmt eine Person mit dem Recht zur Schlüsselverwaltung vor; Tarif und sensible Bereiche werden wie bei der Ausstellung geprüft.

Personenbezogene Daten

Die Schnittstelle gibt Betriebsdaten aus, personenbezogene Daten nur mit dem Berechtigungsbereich personal-data:read:

Bestellungen und Reklamationen liefern ohne ihn nur Land und Ort, nicht Name, E-Mail, Telefon oder Straße.
Das Kundenverzeichnis (customers:read) liefert allein nur Pseudonym, Shops, Land, Sprache, Anzahlen und Daten. Name, Firma, E-Mail, Telefon und das Marketing-Geschlecht kommen erst mit personal-data:read hinzu, Umsatz und LTV erst mit reports:read: Ein Feld, für das Sie keinen Berechtigungsbereich haben, wird entfernt, nicht auf null gesetzt.
Die Kundenanalyse (customers/performance) enthält überhaupt keine personenbezogenen Daten: Der Kunde ist ein Pseudonym (ein Hash der E-Mail-Adresse), derselbe wie customerEmailHash auf Belegen und im Verzeichnis.
Kontaktdaten von Lieferanten und Partnern des Programms liegen hinter demselben Berechtigungsbereich.
Unterhaltungen mit dem Web-Chatbot (chatbot-conversations:read, sensibel) tragen nur einen zufälligen Schlüssel der Unterhaltung, ohne Name, E-Mail, IP oder Cookie. E-Mail, Telefon und IBAN, die der Kunde in den Text geschrieben hat, gibt erst personal-data:read aus; ohne ihn steht an ihrer Stelle ein Platzhalter.
Bank- und Steuerdaten von Partnern (IBAN, Firmen- und Steuernummern, Rechnungsdaten der Auszahlungen), interne Notizen, Passwörter und Secrets des zweiten Faktors werden nie ausgegeben: Kein Berechtigungsbereich öffnet sie.
Webhooks senden Kennungen und Status, nicht den Inhalt der Bestellung oder Kundendaten.

Jeder Aufruf wird ohne Eingabewerte in das Prüfprotokoll geschrieben, nur mit den Feldnamen und einem Fingerabdruck.

Automatisierungen: der sichere Schreibzugriff auf Entwürfe

Ein KI-Assistent darf eine Automatisierung vorschlagen, er darf sie nicht aktivieren. Mit dem Berechtigungsbereich automations:write (sensibel, nie vorausgewählt, nur einem Menschen mit dem Recht angeboten, Automatisierungen zu bearbeiten):

automations_create_draft legt einen Entwurf im Zustand deaktiviert an; die veröffentlichte Version, Auslöser und Ausführungen berührt er nicht;
automations_update_draft bearbeitet nur einen Entwurf, den noch niemand veröffentlicht hat; ein Entwurf, der gerade im Editor der Anwendung bearbeitet wird, wird nicht überschrieben;
der Entwurf erscheint unter Automatisierungen wie jede andere angefangene Arbeit, und aktivieren, veröffentlichen oder ausführen kann ihn nur ein Mensch in der Anwendung mit dem Recht zur Freigabe;
automations_revision_create_draft schlägt eine Änderung an einer veröffentlichten, auch aktivierten Automatisierung als Revision vor; die laufende Version bleibt unverändert, bis ein Mensch die Revision in den Editor lädt und veröffentlicht (automations_revision_update_draft, automations_revision_discard_draft).

Die Werte von Feldern, die im Editor aus einer Liste gewählt werden (Bestellstatus, Versandart, Zahlungsart, Reklamationsstatus…), liefert automations_options in der Form, die der Editor speichert. Ein Wert, der im Shop nicht existiert, und Platzhaltertext wie DOPLNIT_… sind Validierungsfehler, kein Erfolg.

Das Anlegen ist über clientRequestId idempotent, eine Bearbeitung erfordert expectedVersion, und beide erfordern die catalogVersion aus automations_catalog: Ein veralteter Katalog ist ein Konflikt, kein stiller Schreibzugriff. Ein Entwurf, der auf einen unbekannten Auslöser, einen Shop außerhalb des Berechtigungsbereichs oder einen fremden Webhook-Endpoint verweist, wird nicht gespeichert. Einzelheiten in der MCP-Schnittstelle.

Verfügbarkeiten: ein Änderungsvorschlag, den ein Mensch freigibt

Verfügbarkeiten sind die Einträge der Verfügbarkeitsliste eines bestimmten Shops, die der Shop neben einem Produkt anzeigt, zum Beispiel Auf Lager, Auf Bestellung oder Vorbestellung: ein Name, eine Beschreibung, Einlagerungs- und Lieferzeit in Stunden, eine Bedeutung für Google Shopping und eine Farbe. Sie sind kein Lagerbestand.

availabilities_list und GET /availabilities?market= (Berechtigungsbereich products:read) liefern die Liste eines Shops; market ist Pflicht. Das Feld manageable gibt an, ob sich die Liste dieses Shops aus MitoOps ändern lässt, und reason, warum nicht: PLATFORMA (die Plattform kann es nicht), BEZ_ROZSIRENIA (einem WooCommerce-Shop fehlt das MitoOps-Plugin) oder PROSTREDIE (Schreibzugriffe auf Shops sind in dieser Umgebung abgeschaltet).
availabilities_change_draft (nur MCP, sensibler Berechtigungsbereich availabilities:draft) schreibt nichts in den Shop. Es prüft die Änderung, speichert sie als Vorschlag mit einer Gültigkeit von 24 Stunden und liefert eine Vorschau (jedes Feld vorher und nachher, Warnungen, Blockierungen), die draftId und eine approvalUrl.
In den Shop gelangt der Vorschlag erst, wenn ein Mensch in der Anwendung unter Lager → Verfügbarkeiten → Verwaltung auf Genehmigen und schreiben klickt oder ihn ablehnt. Maßgeblich sind dabei die Rechte dieses Menschen zum Zeitpunkt des Klicks, nicht der Berechtigungsbereich des Schlüssels oder der Einwilligung. Weder ein Modell noch ein Zugriffsschlüssel kann ohne einen Menschen etwas in den Shop schreiben.
availabilities_draft_get und GET /availabilities/drafts/:draftId (Berechtigungsbereich products:read) liefern den Status des Vorschlags: pending, writing, executed, partial, failed, rejected oder expired.

Der Berechtigungsbereich availabilities:draft wird nur einem Menschen angeboten, der die Änderung auch freigeben dürfte (die Rechte, den Lagerabgleich zu verwalten und Produkte zu bearbeiten). Ein bestehender Schlüssel oder eine bestehende Einwilligung erbt ihn nicht. REST v1 bleibt nur lesend. Die Parameter des Vorschlags stehen in der MCP-Schnittstelle, die Freigabeansicht in der Anleitung Verfügbarkeiten.

Reklamationen: Einstellungen zum Lesen und ein Änderungsvorschlag

claims_settings (Berechtigungsbereich claims:read) liefert die Prozesse mit IDs und Namen der Typen, Schritte und Status sowie die Tags; mit dem Berechtigungsbereich claims-settings:read auch die Moduleinstellungen.
claims_templates und claims_configuration (Berechtigungsbereich claims-settings:read) liefern E-Mail- und Dokumentvorlagen (Betreff, Text, wann und ob sie automatisch versendet werden) und die übrigen Einstellungen: Tags, Felder, Rückversand und das Formular im Shop, ohne das Integrationstoken.
claims_get trägt außerdem die Zeitachse des Falls, versendete E-Mails und Tags; den Text der Nachrichten nur mit personal-data:read.
claims_config_change_draft (nur MCP, sensibler Berechtigungsbereich claims-settings:draft) ändert die Einstellungen nicht. Es speichert einen Änderungsvorschlag für Prozesse, Status, Tags und Vorlagentexte für 72 Stunden mit Vorschau und approvalUrl; ein Mensch mit dem Recht, die Einstellungen zu verwalten, schreibt ihn mit Freigeben und schreiben unter Reklamationen → Einstellungen, vollständig oder gar nicht. Den Status liefert claims_config_draft_get.

Die Parameter stehen in der MCP-Schnittstelle.

Rückversand, Produkttexte und autonomes Schreiben

claims_routes (Berechtigung claims-settings:read oder eine der Vorschlagsberechtigungen für Reklamationen) liefert Rückversandrouten, Empfängeradressen, Versandprofile mit IDs, Retourenkennzeichen und Reichweite sowie die Schlüssel der Falltypen. claims_routes_change_draft (nur MCP, sensible Berechtigung claims-routes:draft) schlägt vor, eine Route anzulegen, zu ändern, ein- oder auszuschalten. Der Server prüft sie genau wie der Bildschirm: Profil mit aktivierter Retoure, Reichweite des Versanddienstleisters, vorhandene Adresse und Typen, kein negativer Preis und kein Konflikt mit einer eingeschalteten Route. Löschen einer Route über MCP gibt es nicht.
products_content_get und GET /products/:code/content?market= (Berechtigung product-content:read) liefern Beschreibung, Kurzbeschreibung und SEO-Texte eines Produkts direkt aus dem Shop, jedes Feld mit Hash und der Angabe, ob die Plattform es schreiben kann. categories_content_get und GET /categories/:guid/content?market= (Berechtigung category-content:read) liefern dasselbe für eine Kategorie.
products_content_change_draft und categories_content_change_draft (nur MCP, sensible Berechtigungen product-content:draft und category-content:draft) schlagen neue Texte vor, bis zu 30 Einträge auf einmal. Sie akzeptieren nur Inhaltsfelder; Preis, Bestand, Verfügbarkeit, Code, EAN oder Name lassen sich so nicht ändern. HTML wird geprüft: kein Skript außer einem JSON-LD-FAQPage-Block, kein on…, javascript: oder iframe. Bei der Freigabe wird der Text mit dem aktuellen Stand des Shops verglichen; hat ihn inzwischen jemand geändert, wird nichts geschrieben (CHANGED_SINCE_DRAFT). Verändert der Shop den Text beim Speichern, sagt das Ergebnis es (MODIFIED_BY_PLATFORM). Freigegeben wird unter Lager → Produktänderungen. Auf WooCommerce wird ein Entwurf mit Skript (auch JSON-LD) oder Backslash blockiert (PLATFORM_STRIPS_SCRIPT, PLATFORM_STRIPS_BACKSLASH): WordPress entfernt sie beim Speichern und Kunden würden den Rest als Text sehen.
products_content_policy und GET /product-content/policy?market= (Berechtigung product-content:read) sagen ohne Aufruf des Shops, was Ihr Schlüssel im jeweiligen Shop mit Texten tun darf: ob er lesen (readEnabled) und vorschlagen darf (draftEnabled, Vorschläge nur über MCP), welche Felder die Plattform schreibt (supportedFields; SEO-Felder auf WooCommerce nur mit SEO-Plugin), den Freigabemodus (approvalMode: human, autonomous oder disabled) und ob ein Vorschlag automatisch geschrieben wird (autonomousWriteEnabled), Limits für Vorschläge und den Hash-Algorithmus (sha256). Ein pausierter Shop, eine nicht unterstützte Plattform oder ein nur lesender Shop-Schlüssel sind status und reason in der Antwort, kein Fehler. Das Feld category enthält dasselbe für Kategorien. Das Feld structuredData sagt, ob die Plattform strukturierte Daten in der Produktbeschreibung behält: auf WooCommerce nicht (NOT_SUPPORTED, PLATFORM_STRIPS_SCRIPT; strukturierte Daten verwaltet dort das Shop-Theme, THEME_MANAGED), auf Shoptet ja (ein FAQPage-Block).
Autonomes Schreiben. Standardmäßig wird jeder Vorschlag (Reklamationseinstellungen und -routen, Produkt- und Kategorietexte) erst durch die Freigabe eines Menschen geschrieben. Ein Administrator kann es je Bereich unter Einstellungen → API & MCP → Schreiben per KI einschalten. Der Vorschlag wird dann sofort geschrieben, auf demselben Weg wie eine Freigabe, im Namen der Person, die der KI den Zugang erteilt hat, und nur wenn diese Person die Änderung gerade jetzt freigeben dürfte. Sonst wartet der Vorschlag und die Antwort sagt, warum. Jede Änderung des Modus wird protokolliert.

Bestehende Schlüssel und Zustimmungen erben die neuen Berechtigungen nicht; eine neue Zustimmung ist nötig.

Ausgehende Webhooks

REST und MCP lesen auf Anfrage. Wenn Ihr System sofort von einem Ereignis erfahren soll (eine neue Bestellung, eine Zahlung, eine Statusänderung, eine Sendung, eine Zustellung, eine Lagerbewegung, eine Rechnung, eine Reklamation), abonniert es dieses über ausgehende Webhooks: MitoOps sendet an Ihren Endpoint einen kurzen Umschlag mit Kennungen, signiert mit HMAC-SHA256, mit Wiederholungen bei einem Fehlschlag und einem Zustellungsprotokoll. Die Details lädt das System anschließend über REST.

Abonnements legt ein Mensch in der Anwendung an, in derselben Ansicht wie die Schlüssel; über REST und MCP werden Endpoints nur gelesen (webhooks:read, ohne das Secret). Ein Endpoint lässt sich auch als Schritt einer Automatisierung verwenden. Einzelheiten unter Ausgehende Webhooks.

Kontolimits

API & MCP und Webhooks sind Teil jedes kostenpflichtigen Tarifs ab Start. Die Tarife unterscheiden sich in der Anzahl aktiver Schlüssel und Endpoints, nicht darin, was sich lesen lässt:

Tarif	API & MCP	Aktive Zugriffsschlüssel	Webhook-Endpoints
Testversion	—	0	0
Einsteiger	—	0	0
Start	ja	1	5
Wachstum	ja	2	20
Pro	ja	5	50
Maßgeschneidert	ja	nach Vereinbarung	nach Vereinbarung

Die Limits setzt der Server durch: Ein Versuch, einen Schlüssel oder Endpoint über das Limit hinaus hinzuzufügen, wird mit einer Erklärung abgelehnt. Das Ersetzen eines Schlüssels und das Austauschen des Secrets eines Endpoints verbrauchen keinen Platz. Ein Wechsel in einen niedrigeren Tarif widerruft bestehende Schlüssel und Endpoints nicht: Es lässt sich nur kein neuer anlegen, bis die Anzahl unter die neue Obergrenze sinkt. Eine Verbindung über OAuth verbraucht keinen Schlüssel.

Die aktuellen Werte für Ihr Konto einschließlich der Nutzung (aktive Automatisierungen, Ausführungen im laufenden Monat, E-Mails, Credits) liefert account_entitlements / GET /account/entitlements mit dem Berechtigungsbereich account:read. Die Antwort enthält nur Tarif, Funktionen und Limits, keine Rechnungsdaten. Die aktuelle Preisliste finden Sie unter mitoops.com/en/cennik.

Aufruflimits

Limit	Gemessen an	Wie viel
vor der Authentifizierung	der Adresse, von der aus Sie aufrufen	300 Aufrufe / 60 s
nach der Authentifizierung	dem konkreten Schlüssel	600 Aufrufe / 60 s

Das erste verhindert das Erraten von Schlüsseln, das zweite gehört Ihnen allein und wird mit niemandem geteilt. Eine Überschreitung ergibt 429 mit den Headern RateLimit-*. Es ist keine Tarifgröße: Aufrufe werden nicht abgerechnet.

Fehler

Eine Fehlerantwort hat immer dieselbe Form und trägt einen Code:

{ "error": { "code": "store_required", "message": "…", "requestId": "…" } }

Status	Code	Wann
`400`	`invalid_request`	ein Parameter entspricht nicht der Beschreibung (falsches Datum, umgekehrter Zeitraum, ungültiger Cursor)
`400`	`store_required`	ein Aufruf über Shop-Daten ohne `market`
`401`	`unauthorized`	fehlender, unbekannter, widerrufener oder ungültiger Schlüssel
`403`	`forbidden`	dem Schlüssel fehlt der erforderliche Berechtigungsbereich
`403`	`store_forbidden`	ein Shop außerhalb des Berechtigungsbereichs des Schlüssels
`404`	`not_found`	der Datensatz existiert nicht (auch dann, wenn er zu einem anderen Shop gehört)
`405`	—	alles außer `GET` (REST)
`409`	`conflict`	das Schreiben eines Entwurfs ist auf eine andere Version, eine bereits verwendete `clientRequestId` oder einen geänderten Katalog gestoßen (MCP)
`429`	`rate_limited`	technisches Aufruflimit überschritten

Der Grund für ein 401 wird nicht unterschieden: Der Unterschied würde demjenigen helfen, der Schlüssel errät. Geben Sie die requestId an, wenn Sie dem Support ein Problem melden. Über MCP kommt ein Fehler, den der Assistent beheben kann, als Tool-Ergebnis mit dem Kennzeichen isError; ein Protokollfehler als JSON-RPC-Fehler.

Beispiele

# Bestellungen eines Zeitraums, seitenweise
curl -H "Authorization: Bearer <Ihr Schlüssel>" \
  "https://<Ihre Adresse>/api/v1/orders?market=sk&from=2026-08-01&to=2026-08-31&limit=50"

# Zustellstatistik für August
curl -H "Authorization: Bearer <Ihr Schlüssel>" \
  "https://<Ihre Adresse>/api/v1/shipping/stats?market=sk&from=2026-08-01&to=2026-08-31"

# Reklamationsstatistik für August
curl -H "Authorization: Bearer <Ihr Schlüssel>" \
  "https://<Ihre Adresse>/api/v1/claims/statistics?market=sk&from=2026-08-01&to=2026-08-31"

# Tarif und Limits des Kontos mit Nutzung
curl -H "Authorization: Bearer <Ihr Schlüssel>" \
  "https://<Ihre Adresse>/api/v1/account/entitlements"

Fragen, die Claude.ai nach der Verbindung aus den Daten von MitoOps beantwortet: „Wie hoch war der Median der Zustellzeit bei DHL und GLS im August?“, „Wie viele Bestellungen kamen von ChatGPT?“, „Wie hoch ist die Marge von Produkt X im letzten Monat?“ (mit purchase-prices:read), „Wie viele Reklamationen sind überfällig?“, „Schlage eine Automatisierung vor, die drei Tage nach einer unbezahlten Bestellung eine Erinnerung sendet“ (mit automations:write entsteht ein deaktivierter Entwurf), „Benenne im SK-Shop die Verfügbarkeit Auf Bestellung in Innerhalb von 5 Tagen um“ (mit availabilities:draft entsteht ein Vorschlag, den Sie durch Freigabe in der Anwendung schreiben).

Sicherheit

Mandantentrennung. Der Mandant ergibt sich ausschließlich aus dem Berechtigungsnachweis; jeder Mandant hat eine eigene Datenbank.
Der Shop-Umfang ist die Schnittmenge aus der Liste im Berechtigungsnachweis und den Shops, die in diesem Moment verbunden sind. Bei Aufrufen über die Daten eines einzelnen Shops ist market Pflicht: Ein fehlender Shop ergibt 400, ein Shop außerhalb des Berechtigungsbereichs 403.
Die Rechte des Menschen. Der Einwilligungsbildschirm bietet nur Berechtigungsbereiche an, die der angemeldete Mensch selbst hat; es entscheidet der eigene Berechtigungssatz des Kontos.
Die Grenzen jedes Schreibzugriffs setzt der Dienst durch, nicht eine Annotation: Ein Automatisierungsentwurf entsteht immer deaktiviert, eine veröffentlichte Automatisierung wird über MCP nie geändert, und ein Änderungsvorschlag für Verfügbarkeiten schreibt nichts in den Shop, bis ein Mensch ihn in der Anwendung freigibt.
Gültigkeit und Widerruf. Ein OAuth-Zugriffstoken gilt eine Stunde, ein Aktualisierungstoken 30 Tage; eine widerrufene Einwilligung stoppt jedes daraus entstandene Token. Schlüssel lassen sich sofort widerrufen oder ersetzen.
Prüfprotokoll. Jeder Aufruf wird mit dem Namen der Fähigkeit, der Schnittstelle und einem Fingerabdruck der Eingabe aufgezeichnet, ohne Werte.
Worauf Sie sich nicht verlassen können: nicht öffentliche Adressen der Anwendung (die Schnittstelle ist /api/v1 und /api/mcp, sonst nichts), direkter Datenbankzugriff (gibt es nicht) und Zugangsdaten (die Schnittstelle gibt sie nie aus).