/products stellt Ihnen eine Schnittstelle bereit, mit der Sie Produktdaten und Lagerbestände in unserem Shop-System verwalten können. Darüber können Sie Produkte erstellen, bearbeiten, filtern, abrufen und löschen sowie Lagerbestandsinformationen zu Produkten abrufen, aktualisieren und löschen.
Unterstützte Methoden
Datenfelder
Felder werden in der Konfiguration verwaltet und als ein JSON-Objekt in der Tabelle gespeichert. Es wird unterschieden zwischen Standardproduktdatenfeldern und benutzerdefinierten Produktdatenfeldern. Benutzerdefinierte Produktdatenfelder können beliebig angelegt werden, während Standardproduktdatenfelder vom Shop vorgegeben werden und immer definiert sind. Alle benutzerdefinierte Produktdatenfelder sind im Abschnitt custom zu finden. Alle anderen Einträge stellen Standardproduktdatenfelder dar.Beispielhafter Datensatz
Zeitgesteuerte Preise (Aktionspreise)
Produkte können Preise mit einem Gültigkeitszeitraum tragen. Damit lassen sich Aktionspreise im Voraus pflegen, ohne dass zum Aktionsstart ein Import oder eine manuelle Änderung nötig ist. Dieser Abschnitt beschreibt zuerst das Format der Preisfelder in Antworten, danach das erlaubte Format in Requests, anschließend die Wirkung im Shop und zuletzt die Validierung. Wer nur wissen will, was an bestehenden Anbindungen anzupassen ist, findet die kurze Antwort im folgenden Hinweis.Preisfelder in Antworten
Ein Preisfeld enthält den Standardpreis und die Liste der geplanten Aktionspreise. Die ListescheduledPrices ist immer vorhanden. Sind keine Aktionspreise gepflegt, wird sie als leeres Array ausgeliefert.
Antwort (Auszug)
Parameterübersicht
Der Zeitraum ist an beiden Enden einschließend. Ein Eintrag mit
endDate auf 2026-08-31T23:59:59.000Z ist zu genau dieser Sekunde noch aktiv.null sein. Der Typ eines Preisfelds ist für Anbindungen deshalb object | null. Wann dieser Fall auftritt, beschreibt der Abschnitt Methoden für Produktvarianten.
Preisfelder in Requests
Eingehend bleibt die Schnittstelle abwärtskompatibel. Ein Preisfeld darf weiterhin als reiner String übergeben werden. Bestehende Schreibzugriffe funktionieren damit unverändert weiter. Angepasst werden muss nur, wer Aktionspreise über die Schnittstelle pflegen will. Alternativ nimmt die Schnittstelle das Objekt in derselben Struktur an, in der sie es ausliefert. Wird das FeldscheduledPrices nicht mitgeschickt, bleiben bestehende Einträge erhalten. Ein leer übergebenes Array löscht alle Einträge.
Request Body (Auszug)
Wirkung im Shop
Zu jedem Zeitpunkt wird genau ein Preis aufgelöst. Die Auflösung geschieht bei jeder Anfrage neu, es wird also kein Preis vorberechnet und gespeichert. Welcher Preis gilt, entscheiden drei Regeln. Erstens greift ein Aktionspreis nur dann, wenn er den Standardpreis nicht überschreitet. Einträge über dem Standardpreis werden bei der Auflösung übersprungen. In diesem Fall bleibt der Standardpreis gültig. Zweitens wird bei mehreren gleichzeitig aktiven Einträgen der niedrigste Preis verwendet. Bei gleichem Preis gewinnt der Eintrag mit dem späterenstartDate, ein offener Beginn verliert also. Sind auch die Startzeitpunkte gleich, entscheidet die Reihenfolge im Array.
Drittens ersetzt ein eigenes Preisfeld an einer Variante den Standardpreis und den Zeitplan des Basisprodukts gemeinsam. Mehr dazu im Abschnitt Methoden für Produktvarianten.
Für den Suchindex gilt eine Einschränkung. Preisfelder werden ausschließlich mit ihrem Standardpreis indexiert. Geplante Aktionspreise stehen im Index nicht zur Verfügung und können deshalb nicht gefiltert oder sortiert werden.
Validierung und Fehlerschlüssel
Jeder Eintrag wird einzeln geprüft. Fehlerhafte Angaben führen zu400 Bad Request. Der Fehlerschlüssel enthält den Index des betroffenen Eintrags im Array.
Geprüft wird ausschließlich der Eintrag selbst. Ein Vergleich mit dem Standardpreis oder mit anderen Einträgen findet nicht statt. Überlappende Zeiträume und Preise über dem Standardpreis führen deshalb nicht zu einem Fehler, sondern wirken sich erst bei der Auflösung aus. Welcher Eintrag dann greift, beschreibt der Abschnitt Wirkung im Shop.
Hinweis zum internen Speicherformat
Für Werkzeuge, die direkt auf dem gespeicherten Datenblob eines Produkts oder einer Kategorie arbeiten, gilt eine Besonderheit. Dort tragen die beiden Wrapper eine andere Bezeichnung als im REST-Vertrag. Die inneren Schlüssel eines Eintrags sind identisch.
Beide Lesepfade akzeptieren zusätzlich das alte Format als reinen String. Bestandsdaten müssen dafür nicht migriert werden.
Methoden für Produkte
Die hier dokumentierten Endpunkte ermöglichen den Lese-, Schreib-, Änderungs- und Löschzugriff auf Produktdaten im Shopsystem. Sie können zur Verwaltung des Produktkatalogs genutzt werden, sowohl zur Initialbefüllung als auch zur laufenden Aktualisierung von Inhalten. Zusätzlich stehen Endpunkte zur Verfügung, um Produktsuchen auf Basis definierter Regeln durchzuführen. Da jeder Subshop eine eigene Produktmenge hat, sollen URLs den ParametersubshopId enthalten.
Für alle Endpunkte ist eine gültige Authentifizierung erforderlich. Die jeweiligen Berechtigungen zum Lesen, Schreiben, Erstellen oder Löschen von Produkten müssen vorhanden sein.
GET products
Mit diesem Endpunkt können Sie eine Liste aller Produkte im System abrufen. Optional kann die Ergebnismenge mithilfe von Filterparametern eingeschränkt werden, beispielsweise auf Produkte, die einer bestimmten Kategorie zugeordnet sind (inCategory) oder aus einer bestimmten Kategorie ausgeschlossen werden sollen (notInCategory). Beide Parameter dürfen nicht gleichzeitig verwendet werden.
Wenn der Parameter inCategory verwendet wird, erfolgt die Ausgabe der Produkte nicht in der im Shop gepflegten Reihenfolge innerhalb der Kategorie. Um die Produkte in der korrekten Reihenfolge zu erhalten, verwenden Sie bitte den Endpunkt GET categories/{categoryId}/products.
Damit der Endpunkt verwendet werden kann, müssen die entsprechenden Berechtigungen zum Lesen von Produkten vorhanden sein.
Beispiel
Antwort
Filterfelder
Alle Produktdatenfelder,inCategory, notInCategory, inSetProduct, notInSetProduct
Sortierfelder
Alle ProduktdatenfelderSonstige Parameter
from
Fehlercodes
GET products/
Mit diesem Endpunkt können Sie die vollständigen Daten eines einzelnen Produkts abrufen. Geben Sie dazu die Produkt-ID als Pfadparameter an. Neben den Basisdaten werden auch benutzerdefinierte Felder zurückgegeben. Damit der Endpunkt verwendet werden kann, müssen die entsprechenden Berechtigungen zum Lesen von Produkten vorhanden sein.Beispiel
Antwort
Fehlercodes
GET products//url
Mit diesem Endpunkt können Sie die vollständige URL eines Produkts abrufen. Für die Nutzung dieses Endpunkts sind Leseberechtigungen für Produkt-Daten erforderlich.Beispiel
Antwort
Fehlercodes
GET products/testRule
Mit diesem Endpunkt können Sie gezielt Produkte abrufen, die einer oder mehreren angegebenen Regeln entsprechen. Die Regeln werden als JSON-formatiertes Array in der Query-URL übergeben und ermöglichen eine flexible Filterung nach Produktfeldern wie beispielsweise Aktivitätsstatus, Artikelnummern oder Preisangaben. Die Regeln dürfen nur gültige Felder und zulässige Operatoren enthalten. Damit dieser Endpunkt verwendet werden kann, müssen die entsprechenden Berechtigungen zum Lesen von Produktdaten vorhanden sein.Beispiel
Die Regeln werden in der URL als JSON-Array kodiert und über den Parameterrules übergeben. Um korrekt interpretiert zu werden, muss dieser Parameter URL-dekodiert werden.
- Das Feld
activemuss den Wertalwayshaben.
Es werden nur Produkte berücksichtigt, die dauerhaft aktiv sind. - Die Artikelnummer (
itemNumber) muss die Ziffer „5“ enthalten.
Es werden nur Produkte ausgewählt, deren Artikelnummer irgendwo die „5“ enthält (beispielsweise11-2518).
Filter und Sortierungen auf Preisfeldern greifen auf den Standardpreis zu. Geplante Aktionspreise werden dabei nicht berücksichtigt.
Antwort
Mögliche Werte für mode
gt (größer), gte (größer oder gleich), lt (kleiner), lte (kleiner oder gleich), eq (gleich), neq (ungleich), contains (enthält), notcontains (nicht enthält)
Fehlercodes
POST products
Mit dem Endpunkt/products können neue Produkte im Shop-System angelegt werden. Alle für die Erstellung erforderlichen Produktinformationen müssen im Request Body übergeben werden. Die Antwort enthält die vollständigen Produktdaten des neu erstellten Produkts im JSON-Format.
Zum Erstellen eines Produkts sind entsprechende Berechtigungen erforderlich.
Beispiel
Request Body
Antwort
Fehlercodes
Fehler in geplanten Aktionspreisen werden je Eintrag gemeldet. Die Schlüssel beschreibt der Abschnitt Validierung und Fehlerschlüssel.
PUT products/
Mit dem Endpunktproducts/{productId} können Produktdaten aktualisiert werden. Wird ein Produkt mit der angegebenen ID nicht gefunden, kann bei gesetztem Parameter createMissing=yes automatisch ein neues Produkt angelegt werden.
Die vollständigen Produktdaten müssen im Request-Body übergeben werden.
Das optionale Feld set kann benutzt werden, um andere Produkte zusammen mit dem Aktuellen einem Set zuzuweisen. Alternativ können die Endpunkte für Set-Produkte genutzt werden.
Zum Bearbeiten oder Anlegen eines Produkts sind entsprechende Berechtigungen erforderlich.
Beispiel
Request-Body
Antwort
Die Antwort enthält keinen Set-Preis. Er wird nicht gespeichert, sondern bei Bedarf berechnet. Wie Sie ihn abrufen, beschreibt der Abschnitt POST products/setproducts/preview.
Fehlercodes
DELETE products/
Mit dem Endpunktproducts/{productId} kann ein Produkt mit der angegebenen ID dauerhaft gelöscht werden.
Dieser Vorgang entfernt das Produkt vollständig aus dem System.
Zum Löschen eines Produkts sind entsprechende Berechtigungen erforderlich.
Beispiel
Antwort
Fehlercodes
Bulk-Methoden für Produkte
In diesem Abschnitt werden die Bulk-Endpunkte beschrieben, mit denen mehrere Datensätze in einem einzigen Request abgefragt oder verarbeitet werden können.POST bulk/products
Ermöglicht das massenhafte Erstellen und Aktualisieren von Produktdaten in einem einzigen Request. Der Request-Body ist ein JSON-Array, in dem jedes Element ein Produkt mit ID beschreibt. Erstell- und Schreibrechte für Produkte sind erforderlich. Standardmäßig werden nur Produkte aktualisiert. Wird der Parameter createMissing=yes gesetzt, dann werden Produkte in der Anfrage die noch nicht existieren automatisch neues angelegt. In einem Request können maximal 1000 Einträge verarbeitet werden.Beispiel
Request Body
Antwort
Fehlercodes
Methoden für Variantenattribute
Mit den Endpunkten im Bereichproducts/variants/ lassen sich die Variantenattribute und zugehörige Optionen verwalten, die zur Bildung von Produktvarianten im Shop verwendet werden. Sie können neue Attribut-Optionen hinzufügen, bestehende anpassen oder Attribute löschen. Ebenso können Sie die Anzeige-Reihenfolge von Optionen ändern oder gezielt einzelne Optionen abfragen.
Für alle hier dokumentierten Endpunkte ist eine gültige Authentifizierung erforderlich. Zusätzlich benötigen Sie die Berechtigungen zum Lesen, Erstellen oder Bearbeiten von Produktdaten.
GET products/variants
Mit diesem Endpunkt kann eine Liste aller im Shop-System definierten Varianten-Attribute und deren verfügbaren Optionen abgerufen werden. Die Antwort gibt Aufschluss darüber, welche Attributnamen (beispielsweise „Größe“, „Farbe“) verwendet werden und welche Ausprägungen pro Attribut zur Verfügung stehen. Dies ist besonders hilfreich für das Anlegen oder Bearbeiten von Produktvarianten. Für diesen Endpunkt ist eine gültige Authentifizierung erforderlich. Sie müssen über die Berechtigung zum Lesen von Produkten verfügen.Beispiel
Antwort
Fehlercodes
GET products/variants/
Mit diesem Endpunkt kann entweder ein Varianten-Attribut mit seinen zugehörigen Optionen oder eine einzelne Variante-Option abgerufen werden. Wird in der URL ein Attributname (beispielsweise „Farbe“) übergeben, liefert die Antwort alle Optionen zu diesem Attribut. Wird hingegen eine Options-ID übergeben, muss zusätzlich der ParametersingleOption=yes gesetzt werden, um die Daten zu einer konkreten Variante-Option abzurufen. Die Suche nach dem Attributnamen erfolgt unabhängig von der Groß-/Kleinschreibung.
Für die Nutzung dieses Endpunkts ist eine gültige Authentifizierung notwendig. Sie benötigen die Berechtigung zum Lesen von Produkten.
Beispiel (Attribut)
Antwort (Attribut)
Beispiel (Option)
Antwort (Option)
Fehlercodes
POST products/variants
Mit diesem Endpunkt wird ein neues Varianten-Attribut mit beliebigen Optionswerten erstellt. Sollte das Attribut bereits existieren (Groß-/Kleinschreibung wird nicht berücksichtigt), wird es um die neuen, bislang nicht vorhandenen Optionen ergänzt. Ist eine der angegebenen Optionen für das Attribut bereits vorhanden, wird der Vorgang mit einem Konfliktfehler (409) abgebrochen. Für die Nutzung dieses Endpunkts ist eine gültige Authentifizierung erforderlich. Sie benötigen die Berechtigung zum Erstellen von Produkten.Beispiel
Request-Body
Antwort
Fehlercodes
PUT products/variants/
Mit diesem Endpunkt wird ein bestehendes Varianten-Attribut aktualisiert. Die Suche nach dem Attributnamen erfolgt unabhängig von der Groß-/Kleinschreibung. Es können neue Optionen hinzugefügt, bestehende bearbeitet und die Reihenfolge der Optionen geändert werden. Das Umbenennen des Attributs ist über den optionalen ParameternewAttributeName möglich. Bereits existierende Optionen, die im Request-Body nicht enthalten sind, bleiben unverändert bestehen.
Für die Nutzung dieses Endpunkts ist eine gültige Authentifizierung erforderlich. Sie benötigen die Berechtigung zum Schreiben von Produkten.
Beispiel
Request-Body
Antwort
Fehlercodes
DELETE products/variants/
Mit diesem Endpunkt können Sie entweder ein Varianten-Attribut samt aller zugehörigen Optionen oder eine einzelne Option löschen. Wird das Attribut derzeit noch von einem Produkt verwendet, wird der Vorgang mit einem Konfliktfehler abgebrochen. Für die Nutzung dieses Endpunkts ist eine gültige Authentifizierung erforderlich. Sie benötigen die Berechtigung zum Löschen von Produktdaten. Wird in der URL ein Attributname übergeben, werden das Attribut und alle zugehörigen Optionen gelöscht. Die Suche nach dem Attributnamen erfolgt unabhängig von der Groß-/Kleinschreibung. Wird hingegen eine Options-ID übergeben, muss zusätzlich der ParametersingleOption=yes gesetzt werden, um nur diese einzelne Option zu löschen.
Beispiel (Attribut)
Antwort (Attribut)
Beispiel (Option)
Antwort (Option)
Fehlercodes
Methoden für Produktvarianten
Die folgenden Endpunkte ermöglichen das Verwalten von Produktvarianten innerhalb eines bestehenden Produkts. Varianten stellen spezifische Ausprägungen eines Produkts dar (beispielsweise Größen oder Farben) und basieren auf den zuvor definierten Variantenattributen. Die API erlaubt es, Varianten einzeln abzurufen, zu erstellen, zu aktualisieren oder zu löschen sowie komplette Variantenkombinationen automatisch zu erzeugen. Für alle Endpunkte in diesem Abschnitt ist sicherzustellen, dass die entsprechenden Lese-, Schreib- oder Löschberechtigungen für Produktvarianten vorliegen. Auch Varianten tragen ihren Preis als Objekt. Setzt eine Variante ein eigenes Preisfeld, ersetzt dieses den Standardpreis und den Zeitplan des Basisprodukts gemeinsam. Eine Variante mit eigenem Preis und ohne Aktionspreise erbt die Aktion des Basisprodukts also nicht. Setzt eine Variante kein eigenes Preisfeld, liefert die Antwort für dieses Feldnull und nicht den Wert des Basisprodukts. Anbindungen müssen diesen Fall abfangen, der Typ ist object | null.
GET products//variants
Mit diesem Endpunkt kann eine Liste aller Varianten für das angegebene Produkt geladen werden. Varianten sind Produktversionen, die sich durch unterschiedliche Attributkombinationen (beispielsweise Größe oder Farbe) vom Hauptprodukt unterscheiden. Die Antwort enthält grundlegende Produktdaten sowie die zugehörigen Attributwerte unterselection.
Um diesen Endpunkt nutzen zu können, sind entsprechende Berechtigungen zum Lesen von Produktvarianten erforderlich.
Beispiel
Antwort
Fehlercodes
GET products//variants/
Mit diesem Endpunkt kann eine bestimmte Produktvariante anhand ihrer ID innerhalb eines Produkts geladen werden. Die Produkt-ID wird als Teil der URL übergeben, ebenso die Varianten-ID. Die Antwort enthält die zugehörigen Variantendaten inklusive Preis, Artikelnummer, Auswahlattribute (selection) und weiterer Detailinformationen.
Für die Nutzung dieses Endpunkts sind entsprechende Berechtigungen zum Lesen von Produktvarianten erforderlich.
Beispiel
Antwort
Fehlercodes
PUT products//variants/
Mit diesem Endpunkt können die Daten einer bestimmten Produktvariante anhand ihrer Produkt-ID und Varianten-ID aktualisiert werden. Die Variante wird anhand der angegebenen ID identifiziert und mit den im Request-Body übermittelten Werten überschrieben. Für die Nutzung dieses Endpunkts sind Schreibrechte für Produktvarianten erforderlich.Beispiel
Request-Body
Antwort
Fehlercodes
POST products//variantAttributes
Mit diesem Endpunkt können für ein bestimmtes Produkt Varianten automatisch aus den übergebenen Attributen erzeugt werden. Dabei wird jede mögliche Kombination der Attribut-Optionen als eigene Produktvariante angelegt. Wenn dem Produkt bisher nicht zugewiesene Attribute ergänzt oder vorhandene Attribute entfernt werden, wird der Vorgang standardmäßig abgebrochen und es wird ein 400-Fehler mit dem Fehlertypconflict zurückgegeben. Um diesen Abbruch zu umgehen, kann der optionale Parameter force=yes verwendet werden. In diesem Fall werden alle bisherigen Kombinationen gelöscht und durch die neuen ersetzt.
Für die Nutzung dieses Endpunkts sind Schreibrechte für Produktvarianten erforderlich.
Beispiel
Request-Body
Antwort
Fehlercodes
POST products//variants/manage
Dieser Endpunkt ermöglicht es, gezielt bestimmte Varianten-Kombinationen für ein bestehendes Produkt anzulegen. Anders als beim EndpunktPOST products/{productId}/variantAttributes, der automatisch alle möglichen Kombinationen aus den angegebenen Attributen generiert, werden hier nur die explizit übermittelten Kombinationen erzeugt. Bereits existierende Kombinationen werden ignoriert. Bei Kollisionen wird ein entsprechender Fehlercode zurückgegeben. Optional können auch IDs übergeben werden.
Der Endpunkt eignet sich besonders, wenn nicht alle theoretisch möglichen Kombinationen eines Produkts benötigt werden, sondern nur eine gezielte Auswahl.
Für die Nutzung sind Schreibrechte für Produktvarianten erforderlich.
Beispiel
Request-Body
Antwort
Fehlercodes
DELETE products//variants/
Mit diesem Endpunkt kann eine bestehende Produktvariante anhand von Produkt-ID und Varianten-ID gelöscht werden. Dies ist etwa dann sinnvoll, wenn bestimmte Kombinationen von Varianten (beispielsweise Größe und Farbe) nicht mehr angeboten werden sollen. Sowohl das übergeordnete Produkt als auch die Variante müssen existieren. Andernfalls wird ein entsprechender Fehler zurückgegeben. Für die Nutzung sind Löschberechtigungen für Produktvarianten erforderlich.Beispiel
Antwort
Fehlercodes
Bulk-Methoden für Varianten
In diesem Abschnitt werden die Bulk-Endpunkte beschrieben, mit denen mehrere Datensätze in einem einzigen Request abgefragt oder verarbeitet werden können.POST bulk/products/variants
Ermöglicht das massenhafte Erstellen und Aktualisieren von Produktdaten in einem einzigen Request. Der Request-Body ist ein JSON-Array, in dem jedes Element ein Produkt beschreibt. Erstell- und Schreibrechte für Produktvarianten sind erforderlich. Für jeden Eintrag wird die jeweilige Produktvariante über die FelderproductId, variantId und selection identifiziert. Zum Aktualisieren einer Variante genügt productId in Kombination mit selection oder variantId. Beim Anlegen einer neuen Variante ist selection verpflichtend. Wird zusätzlich variantId mitgegeben, wird die neue Variante mit dieser ID erstellt.
Standardmäßig werden nur Produktvarianten aktualisiert. Wird der Parameter createMissing=yes gesetzt, dann werden Produktvarianten in der Anfrage die noch nicht existieren automatisch neues angelegt.
In einem Request können maximal 1000 Einträge verarbeitet werden.
Beispiel
Request Body
Antwort
Fehlercodes
Methoden für Lagerbestand Allgemein
Die folgenden Endpunkte ermöglichen das Abrufen, Erstellen, Aktualisieren und Löschen von Lagerbeständen im System. Jeder Lagerbestand wird durch eine eindeutigeinventoryId identifiziert, die üblicherweise mit einer Produkt- oder Varianten-ID übereinstimmt.
Abhängig vom Endpunkt können Lagerbestände direkt gesetzt oder relativ verändert werden, beispielsweise beim Buchen von Zu- oder Abgängen.
Für alle hier dokumentierten Endpunkte ist eine entsprechende Berechtigung für den Zugriff auf Lagerbestände erforderlich.
Alle Endpunkte in diesem Abschnitt unterstützen den optionalen URL-Parameter storageId, mit dem die Lager-ID explizit angegeben werden kann. Wird dieser Parameter nicht gesetzt, wird automatisch die Lager-ID des aktiven Subshops verwendet.
GET products/inventory/
Mit diesem Endpunkt kann der Lagerbestand eines Produkts oder einer Produktvariante anhand der Lagerbestands-ID (inventoryId) abgerufen werden. Die Antwort enthält Informationen über den aktuellen Bestand, offene Bestellungen sowie den Zeitpunkt der letzten Aktualisierung.
Damit der Endpunkt genutzt werden kann, müssen die entsprechenden Berechtigungen zum Lesen von Lagerbeständen vorhanden sein.
Beispiel
Antwort
Fehlercodes
POST products/inventory
Mit diesem Endpunkt wird ein neuer Lagerbestand für ein Produkt oder eine Produktvariante angelegt. Dabei wird eine eindeutige Lagerbestands-ID (id) sowie die verfügbaren und offenen Mengen angegeben.
Damit dieser Endpunkt verwendet werden kann, müssen die entsprechenden Berechtigungen zum Erstellen von Lagerbeständen vorhanden sein.
Beispiel
Request-Body
Antwort
Fehlercodes
PUT products/inventory/
Mit diesem Endpunkt aktualisieren Sie den Lagerbestand eines bestimmten Produkts anhand der übergebenen Parameter. Dabei können Sie sowohl den Bestand (amount) als auch die Anzahl der offenen Bestellungen (openOrder) anpassen, entweder absolut oder relativ:
- Ist
amountTypeaufrelativegesetzt, wird der aktuelle Lagerbestand um den angegebenenamounterhöht. Bei einem negativen Wert wird er verringert. Andernfalls wird der Lagerbestand auf den Wert vonamountgesetzt. - Entsprechend funktioniert
openOrderType. Ist dieser aufrelativegesetzt, wird die Anzahl der offenen Bestellungen umopenOrdererhöht oder bei negativem Wert verringert. OhnerelativewirdopenOrderdirekt gesetzt.
{inventoryId}, kann über den optionalen URL-Parameter createMissing=yes automatisch ein neuer Eintrag angelegt werden.
Um diesen Endpunkt verwenden zu können, benötigen Sie die Berechtigung zum Schreiben von Lagerbeständen.
Beispiel
Request-Body
Antwort
Fehlercodes
DELETE products/inventory/
Mit diesem Endpunkt löschen Sie den Lagerbestand eines Produkts für die angegebene{inventoryId} im aktuellen Subshop. Wenn kein entsprechender Eintrag existiert, wird ein Fehler zurückgegeben.
Um diesen Endpunkt verwenden zu können, benötigen Sie die Berechtigung zum Löschen von Lagerbeständen.
Beispiel
Antwort
Fehlercodes
PUT bulk/products/inventory
Mit diesem Endpunkt können Sie mehrere Lagerbestände gleichzeitig aktualisieren. Die zu aktualisierenden Einträge werden als Array im Request-Body übergeben. Jeder Eintrag muss eineid (Lagerbestands-ID) enthalten. Für jeden Eintrag können sowohl der Bestand (amount) als auch die Anzahl der offenen Bestellungen (openOrder) angepasst werden, entweder absolut oder relativ:
- Ist
amountTypeaufrelativegesetzt, wird der aktuelle Lagerbestand um den angegebenenamounterhöht. Bei einem negativen Wert wird er verringert. Andernfalls wird der Lagerbestand auf den Wert vonamountgesetzt. - Entsprechend funktioniert
openOrderType. Ist dieser aufrelativegesetzt, wird die Anzahl der offenen Bestellungen umopenOrdererhöht oder bei negativem Wert verringert. OhnerelativewirdopenOrderdirekt gesetzt. - Existiert noch kein Lagerbestand für eine angegebene
id, kann über den optionalen URL-ParametercreateMissing=yesautomatisch ein neuer Eintrag angelegt werden. Einträge mit ungültigen Daten werden übersprungen, beispielsweise wennamountkein Number-Typ ist.
Beispiel
Request-Body
Antwort
Fehlercodes
Methoden für Produkte Lagerbestand
Über die folgenden Endpunkte lassen sich lagerbezogene Einstellungen für einzelne Produkte verwalten. Dazu zählen sowohl die Zuordnung zu einem Lagerbestandseintrag als auch die Konfiguration der Darstellung im Shop, beispielsweise farbliche Ampellogik, individuelle Lagermeldungen und Reservierungszeiten. Die Einstellungen greifen dabei direkt auf die allgemeinen Lagerbestände zu, die über die Endpunkte im Abschnitt Methoden für Lagerbestand Allgemein gepflegt werden. Für den Zugriff auf diese Endpunkte sind Lese- oder Schreibrechte für Produktdaten erforderlich, je nach gewählter Operation.GET products//inventory
Mit diesem Endpunkt können Sie die Lagerbestandskonfiguration eines bestimmten Produkts abrufen. Diese Konfiguration umfasst unter anderem Schwellwerte für Ampelfarben, individuelle Lagermeldungen und die Reservierungsdauer. Die AngabestoreId verweist auf einen allgemeinen Lagerbestandseintrag, wie er über die Lagerbestands-Endpunkte verwaltet wird.
Für die Verwendung dieses Endpunkts sind Lese-Berechtigungen für Produktdaten erforderlich.
Beispiel
Antwort
Fehlercodes
PUT products//inventory
Dieser Endpunkt dient dazu, die Lagerbestandseinstellungen eines Produkts zu aktualisieren. Dabei lassen sich beispielsweise die Darstellung im Shop (Ampel-Logik), Lagermeldungen oder die Reservierungszeit anpassen. Die EinstellungstoreId bleibt hierbei unverändert und muss nicht übergeben werden.
Für die Verwendung dieses Endpunkts sind Schreib-Berechtigungen für Produktdaten erforderlich.
Beispiel
Request-Body
Antwort
Fehlercodes
Methoden für Varianten Lagerbestand
Dieses Kapitel beschreibt die Endpunkte zur Verwaltung von lagerbezogenen Einstellungen einzelner Produktvarianten. Wie bei Produkten lassen sich auch für Varianten spezifische Lagerbestandsanzeigen, Ampelgrenzen, individuelle Texte und Reservierungszeiten festlegen. Die Zuordnung erfolgt ebenfalls über einenstoreId, der auf einen zentral gepflegten Lagerbestand verweist.
Für den Zugriff sind entsprechende Lese- oder Schreibrechte auf Produktdaten erforderlich.
GET products//variants//inventory
Ruft die Lagerbestandseinstellungen der Produktvariante mit der angegebenenvariantId ab.
Die Einstellungen beinhalten unter anderem Ampelgrenzen, Verfügbarkeitsanzeige, E-Mail-Benachrichtigungen sowie den Verweis (storeId) auf den zugehörigen zentralen Lagerbestand.
Für diese Abfrage werden Lese-Rechte auf Produktvarianten benötigt.
Beispiel
Antwort
Fehlercodes
PUT products//variants//inventory
Aktualisiert die Lagerbestandseinstellungen der Produktvariante mit der angegebenenvariantId.
Die Konfigurationen wirken sich direkt auf die Darstellung im Shop aus und steuern beispielsweise die Verfügbarkeitsanzeige. Die Verknüpfung zum zentralen Lager erfolgt über das Feld storeId.
Für diese Operation werden Schreibrechte auf Produktvarianten benötigt.
Beispiel
Request-Body
Antwort
Fehlercodes
Methoden für Set-Produkte
Dieses Kapitel beschreibt die Endpunkte zur Verwaltung von Set-Produkten (Produktbündeln). Für den Zugriff sind entsprechende Lese- oder Schreibrechte auf Produktdaten erforderlich. Der Preis eines Sets ist kein gespeicherter Wert. Er wird aus dem Preis des Hauptprodukts und den Preisen der Unterprodukte berechnet, und zwar jedes Mal neu. Wer ihn anzeigen will, ruft ihn über den Endpunkt POST products/setproducts/preview ab. Was das für bestehende Anbindungen bedeutet, steht am Ende dieses Kapitels im Abschnitt Set-Preis wird nicht mehr gespeichert.products//setproducts
Gibt eine Liste mit Unterprodukten zurück, wenn das Produkt mitid=parentProductId einen Set besitzt. Optional kann setParentProductList IDs der Produkte enthalten, zu deren Sets das aktuelle Produkt gehört.
Für diese Abfrage werden Lese-Rechte auf Produktdaten benötigt.
Beispiel
Antwort (Hauptprodukt)
Antwort (Set-Unterprodukt)
Fehlercodes
POST products//setproducts/assign
Produkte aus dem Request Body werden dem Set vom Produkt mitid=parentProductId zugewiesen. Das Feld prodId kann entweder ein einzelner String oder ein Array von Strings sein.
Für diese Abfrage werden Schreib-Rechte auf Produktdaten benötigt.
Beispiel
Request Body
Antwort
Fehlercodes
POST products//setproducts/update/
Daten vom Produkt mitid=childProductId im Set vom Produkt mit id=parentProductId werden aktualisiert.
Für diese Abfrage werden Schreib-Rechte auf Produktdaten benötigt.
Beispiel
Request Body
Antwort
Fehlercodes
POST products/setproducts/preview
Dieser Endpunkt berechnet den Preis eines Set-Produkts aus den übergebenen Werten und gibt das Ergebnis zurück. Er speichert nichts. Damit lässt sich der Set-Preis bereits während der Bearbeitung anzeigen, also noch bevor das Produkt gespeichert wird. Berechnet werden zwei Werte.setPrice ist die Summe aus dem Preis des Hauptprodukts und den Preisen aller Unterprodukte mit usePrice. setOrgPrice ist die Summe aus dem Preis des Hauptprodukts und den Preisen aller Unterprodukte und dient als Referenzpreis. Die Preise werden zum aktuellen Zeitpunkt aufgelöst, aktive Aktionspreise fließen also in beide Werte ein.
Für diese Abfrage werden Schreib-Rechte auf Produktdaten benötigt.
Beispiel
Request Body
Antwort
P1 und 9,99 für P2. setPrice enthält das Hauptprodukt und das zweifache P1, also 19,99 plus 9,98. In setOrgPrice kommt zusätzlich P2 hinzu, weil dort alle Unterprodukte einfließen. Tragen alle Unterprodukte usePrice, sind beide Werte gleich.
Fehlercodes
DELETE products//setproducts/
Das Produkt mitid=childProductId wird aus dem Set vom Produkt mit id=parentProductId entfernt. Gilt childProductId=all, werden alle Produkte aus dem Set entfernt. Gilt parentProductId=all, wird das Produkt mit id=childProductId aus allen Sets entfernt, in denen es enthalten ist.
Für diese Abfrage werden Löschberechtigungen für Produktdaten benötigt.
Beispiel
Antwort
Fehlercodes
Set-Preis wird nicht mehr gespeichert
Der Set-Preis ist kein gespeicherter Wert mehr, sondern wird bei Bedarf berechnet. Die impliziten Neuberechnungen beim Anlegen, Aktualisieren und Löschen von Produkten, bei den Bulk-Endpunkten und im Produktimport sind entfallen. Für Clients bedeutet das zwei Dinge. Erstens liefert kein Endpunkt mehr einen gespeicherten Set-Preis aus. Zweitens muss ein Client, der den Set-Preis anzeigen will, ihn über den Endpunkt POST products/setproducts/preview berechnen lassen.Im Shop wird der Set-Preis weiterhin bei jedem Seitenaufruf berechnet. Die Felder am Template-Objekt haben sich dabei geändert,
setPrice und die zugehörigen Felder stehen nur noch an Set-Produkten. Was das für bestehende Templates bedeutet, beschreibt der Abschnitt Änderungen an bestehenden Templates.Entfernte Felder
Ergänzende Referenzen
- API-Referenz Bildkonverter
- API-Referenz Kategorien
- API-Referenz Konfiguration
- API-Referenz Meta-Daten
- API-Referenz SEO-URLs
- content - Katalog (Kategorien & Produkte)
Hinweis zu Produktdatenfeldern
Neue Produktdatenfelder (zusätzliche Eigenschaften, Attribute oder technische Felder) können nicht direkt über die Produkt-API erstellt werden. Die API dient ausschließlich dem Auslesen und Pflegen vorhandener Felder. Um neue Felder zu definieren, muss die Konfiguration im Knotencontent.customProductField verwendet werden. → content - Katalog (Kategorien & Produkte)
Dort lassen sich individuelle Felder mit Typ, Suchrelevanz, Pflichtstatus und Varianteneigenschaften anlegen. Sobald ein Feld dort konfiguriert wurde, steht es anschließend automatisch in der Produkt-API zur Verfügung, beispielsweise in GET products oder POST products.
