REST-API

Übersicht

Die REST-API von Shoporama ermöglicht es dir, deinen Webshop mit externen Systemen zu integrieren – ERP, Lagerverwaltung, PIM, CRM und anderen Diensten. Die API unterstützt CRUD (Erstellen, Lesen, Aktualisieren, Löschen) für die meisten Ressourcen in deinem Webshop.

Dokumentation

Die vollständige API-Dokumentation mit allen Endpunkten, Parametern und Beispielen findest du in unserer interaktiven Swagger-Dokumentation:

Swagger-Dokumentation öffnen

Hier kannst du API-Aufrufe direkt im Browser testen und alle verfügbaren Felder und Parameter für jede Ressource einsehen.

Erste Schritte

1. Gehe in deiner Shoporama-Verwaltung zu „Integrationen“ → „API-Zugriff“
2. Erstelle einen neuen API-Schlüssel
3. Wählen Sie die Berechtigungen für den Schlüssel aus: Alle, Nur Lesen oder Nur Schreiben. Die Berechtigung gilt für den gesamten Schlüssel, nicht für die einzelne Ressource
4. Verwende den Schlüssel im „Authorization“-Header deiner API-Aufrufe

Authentifizierung

Füge deinen API-Schlüssel in den „Authorization“-Header ein. Du kannst den Schlüssel entweder direkt senden oder das „Bearer“-Format verwenden:

Authorization: IHR-API-SCHLÜSSEL

# Oder mit „Bearer“:
Authorization: Bearer IHR-API-SCHLÜSSEL

Verfügbare Ressourcen

Die API bietet Zugriff auf die folgenden Ressourcen. Alle Endpunkte sind unter https://dinshop.dk/REST/ erreichbar:

Produkte und Katalog

• /product — Produkte (mit Varianten, Bildern, Preisen, Kategorien, Zusatzfeldern)
• /category — Kategorien
• /brand — Marken
• /manufacturer – Hersteller
• /supplier — Lieferanten
• /product-label — Produktbezeichnungen
• /profile, /profile-attribute, /profile-attribute-value — Produktprofile, Attribute und Werte

Lager

• /stock — Lagerbestand und Buchungen
• /batch — Lagerchargen

Bestellungen und Kunden

• /order — Bestellungen
• /order/{id}/create-label — Versandetikett für Bestellung erstellen
• /order/{id}/download-label — Versandetikett herunterladen
• /order-queue — Auftragswarteschlange
• /order-label — Auftragsetiketten
• /order-return — Rücksendungen
• /customer — Kunden
• /customer-field — Kundenfelder
• /voucher — Rabattcodes und Geschenkgutscheine

Inhalt

• /page — Statische Seiten
• /blog-post — Blogbeiträge
• /landing-page und /landing-page-item — Landingpages und Elemente. GET /landing-page/{id} gibt nun die Regeln (rules) und den Match-Typ (match_type) der Seite direkt in der Antwort zurück, sodass du keinen separaten Aufruf an /landing-page-item mehr benötigst
• /menu — Menüs und Navigation

Newsletter

• /newsletter-list — Newsletter-Listen
• /newsletter-subscriber — Abonnenten
• /newsletter-campaign — Kampagnen

Einrichtung

• /shipping — Versandarten
• /payment_gateway — Zahlungsmethoden
• /country — Länder
• /redirect — URL-Weiterleitungen
• /webhook — Webhooks

Theme-Dateien

• /theme-file — Dateien in Ihren Themes lesen, erstellen, aktualisieren und löschen. Erfordert, dass „Zugriff auf Theme-Dateien“ im API-Schlüssel aktiviert ist

HTTP-Methoden

• GET — Eine Liste oder eine einzelne Ressource abrufen
• POST — Eine neue Ressource erstellen
• PUT — Eine vorhandene Ressource aktualisieren
• DELETE – Eine Ressource löschen

Beispiele

Produkte abrufen:

curl -H "Authorization: DIN-API-SCHLÜSSEL" \
  https://dinshop.dk/REST/product?limit=10

Ein Produkt anlegen:

curl -X POST -H "Authorization: DIN-API-SCHLÜSSEL" \
  -H "Content-Type: application/json" \
  -d '{"name": "Neues Produkt", "price": 199,00}' \
  https://dinshop.dk/REST/product

Lagerbestand aktualisieren:

curl -X PUT -H "Authorization: IHR-API-SCHLÜSSEL" \
  -H "Content-Type: application/json" \
  -d '{"count": 50}' \
  https://dinshop.dk/REST/stock/123

Die Zahl im Pfad ist die Produkt-ID, und „count“ ist der neue Gesamtbestand.

Filterung und Paginierung

Listen-Endpunkte unterstützen die folgenden Abfrageparameter:

• ?limit=25 — Anzahl der Ergebnisse pro Seite. Die Obergrenze hängt vom Endpunkt ab (z. B. 250 bei /product) und ist der Swagger-Dokumentation zu entnehmen
• ?offset=0 – Ergebnisse überspringen (für die Paginierung)
• ?search=Text — Freitextsuche
• ?fields=name,price — Einschränkung der zurückgegebenen Felder
• ?last_modified=2026-01-01 — nur Ressourcen, die seit diesem Datum geändert wurden

Webhooks

Sie können über die API Webhooks einrichten, damit Ihr System automatisch benachrichtigt wird, wenn Änderungen auftreten. Bei der Einrichtung erhalten Sie einen Secret, der zur Verifizierung von Webhook-Aufrufen über HMAC verwendet wird.

Statuscodes

• 200 — Erfolgreich
• 201 – Ressource erstellt
• 204 – Aktualisierung/Löschung erfolgreich
• 400 – Ungültige Anfrage
• 401 — Nicht autorisiert (falscher oder fehlender API-Schlüssel)
• 403 — Der Schlüssel ist gültig, verfügt jedoch nicht über die erforderlichen Berechtigungen für die Aktion (z. B. ein Schlüssel mit „Nur Lesen“-Berechtigung, der versucht zu schreiben)
• 404 — Ressource nicht gefunden
• 429 — Zu viele Aufrufe (Ratenbegrenzung)

Das API-Protokoll: Sehen Sie, was tatsächlich aufgerufen wird

Jeder API-Schlüssel verfügt über ein eigenes Protokoll der eingegangenen Aufrufe. Dies ist das Tool, das Sie verwenden sollten, wenn sich eine Integration anders als erwartet verhält, denn das Protokoll zeigt, was tatsächlich in Ihrem Shop angekommen ist – und nicht, was der externe Anbieter glaubt, dass gesendet wurde.

So findest du das Protokoll

1. Gehe zu „Integrationen“ → „API-Zugriff“
2. Suchen Sie in der Liste den Schlüssel, den die Integration verwendet
3. Klicken Sie auf die Schaltfläche „Protokoll anzeigen“ für den Schlüssel

Das Protokoll gehört immer zu einem bestimmten Schlüssel, und es gibt kein übergreifendes Protokoll für alle Schlüssel. Daher lohnt es sich, pro Integration einen Schlüssel mit einem aussagekräftigen Namen anzulegen, damit du genau sehen kannst, was der jeweilige Dienst tut. Oben auf der Seite stehen der Name des Schlüssels, der Schlüssel selbst und die Anzahl der Einträge.

Das zeigt das Protokoll an

• Zeitpunkt: Wie lange ist es her, dass der Aufruf eingegangen ist, z. B. „vor 3 Stunden“. Bewegen Sie den Mauszeiger darüber, um das genaue Datum und die Uhrzeit auf die Sekunde genau anzuzeigen
• Methode: GET, POST, PUT, DELETE oder PATCH, dargestellt als farbige Markierung
• Pfad: Der aufgerufene Endpunkt ohne Domäne, z. B. „product“ oder „order/3658“
• Parameter: Die Query-Zeichenkette des Aufrufs, z. B. „limit=50&offset=0“. Das Feld ist leer, wenn der Aufruf keine Parameter enthielt, und sehr lange Zeichenketten werden gekürzt angezeigt
• IP: Die IP-Adresse des Absenders
• User-Agent: welches Programm den Aufruf getätigt hat, z. B. ein Befehlszeilen-Tool oder der eigene Client-Name der Integration. Bewegen Sie den Mauszeiger darüber, um den vollständigen Wert anzuzeigen

Sortieren, filtern und suchen

Sie können nach Zeitpunkt, Methode, Pfad und IP sortieren, indem Sie auf die Spaltenüberschrift klicken. Standardmäßig werden die neuesten Aufrufe ganz oben angezeigt. Die Werte in den Spalten „Methode“, „Pfad“, „IP“ und „User-Agent“ sind gleichzeitig anklickbar und fungieren als Verknüpfungen:

• Klicken Sie auf eine Methode, um beispielsweise nur alle PUT-Aufrufe anzuzeigen. Der Filter wird oben auf der Seite angezeigt und kann über das Kreuz wieder entfernt werden
• Klicken Sie auf einen Pfad, um alle Aufrufe bis zu diesem Endpunkt anzuzeigen
• Klicken Sie auf eine IP-Adresse, um alle Aktivitäten dieses Absenders anzuzeigen, oder auf einen User-Agent, um alle Aufrufe desselben Programms anzuzeigen

Das Suchfeld durchsucht gleichzeitig Pfad, Parameter, IP und User-Agent. Die Anzahl der Einträge oben auf der Seite richtet sich nach dem Filter, sodass du sie als Zähler verwenden kannst. Du kannst 25, 50, 100 oder 200 Einträge pro Seite anzeigen lassen, und die Auswahl wird für das nächste Mal gespeichert, wenn du das Protokoll öffnest.

Das zeigt das Protokoll nicht an

Das Protokoll ist eine Übersicht über eingehende Aufrufe, keine vollständige technische Nachverfolgung. Drei Dinge werden bewusst nicht gespeichert:

• Der Statuscode: Du kannst nicht sehen, ob ein Aufruf mit 200 oder 404 endete. Dies musst du in deinem eigenen Integrationsprotokoll nachlesen
• Der Inhalt des Aufrufs: Das JSON, das du mit POST und PUT sendest, wird nicht gespeichert. Die Spalte „Parameter“ zeigt nur das an, was nach dem Fragezeichen in der Adresse steht
• Die Antwort: Die von der API zurückgegebenen Daten werden ebenfalls nicht gespeichert

Aufrufe, die aufgrund des Schlüssels selbst abgelehnt werden, erscheinen ebenfalls nicht im Protokoll. Wird ein Aufruf mit dem Status 401 abgelehnt, weil der Schlüssel falsch ist, fehlt oder gelöscht wurde, wird er nie mit einem Schlüssel verknüpft, und es gibt daher keine Zeile, die protokolliert werden könnte. Aufrufe, die mit 403 (der Schlüssel darf die versuchte Aktion nicht ausführen), 404 (unbekannter Endpunkt), 405 (falsche Methode) oder 429 (tägliches Limit erreicht) enden, werden hingegen im Protokoll aufgeführt, da der Schlüssel zuvor autorisiert wurde.

Das API-Protokoll umfasst Aufrufe an Ihren Shop. Wenn bei Webhooks – also Aufrufen von Ihrem Shop aus – Fehler auftreten, finden Sie deren eigenes Protokoll unter „Integrationen“ → „Webhooks“.

Wie lange werden die Einträge gespeichert?

Einträge im API-Protokoll werden acht Wochen lang gespeichert und anschließend automatisch gelöscht. Dies ist auch unten auf der Protokollseite selbst vermerkt. Acht Wochen reichen völlig aus, um eine Integration zu überprüfen, bedeuten aber, dass das Protokoll nicht als Dokumentation für vergangene Jahre herangezogen werden kann. Wenn du einen längeren Verlauf benötigst, muss dieser auf der anderen Seite gespeichert werden, also in dem System, das den Aufruf tätigt.

Die Kenntnis dieser Frist hat einen zusätzlichen Vorteil: Die Spalte „Zuletzt verwendet“ auf der API-Zugriffsseite wird anhand des neuesten Eintrags im Protokoll berechnet. Wurde ein Schlüssel länger als acht Wochen nicht verwendet, verschwindet sein letzter Eintrag, und die Spalte zeigt statt eines Datums einen Strich an. Ein Strich bedeutet also „innerhalb der letzten acht Wochen nicht verwendet“, nicht unbedingt „nie verwendet“. Dies ist eine effektive Methode, um alte Schlüssel zu finden, die bedenkenlos gelöscht werden können.

Fehlerbehebung bei einer Integration, die sich nicht wie erwartet verhält

Wenn eine Integration nicht wie vorgesehen funktioniert, lautet die erste Frage immer dieselbe: Ist der Aufruf überhaupt angekommen? Das API-Protokoll gibt innerhalb weniger Sekunden Antwort darauf – und zwar unabhängig davon, was der Anbieter des anderen Systems davon hält. Gehen Sie die Schritte der Reihe nach durch.

Schritt 1: Sind die Aufrufe überhaupt angekommen?

Öffne das Protokoll für den Schlüssel, den die Integration verwendet, und überprüfe die Zeitstempel in dem Zeitraum, in dem etwas hätte passieren sollen.

• Überhaupt keine Einträge: Dann liegt das Problem auf der anderen Seite. Entweder ruft die Integration gar nicht an, oder der Aufruf wird aufgrund des Schlüssels abgelehnt. Überprüfe, ob sie mit dem richtigen Schlüssel und der richtigen Adresse deines Shops eingerichtet ist und ob der Schlüssel nicht gelöscht wurde
• Zeilen bis zu einem bestimmten Zeitpunkt, danach nichts: Dann ist die Integration an dieser Stelle ausgefallen. Notieren Sie sich den Zeitpunkt. Das ist fast immer genau die Information, die Sie benötigen, um die Ursache im anderen System zu finden
• Einträge über den gesamten Zeitraum: Die Aufrufe werden übertragen, und der Fehler liegt in dem, was aufgerufen wird. Fahre mit Schritt 2 fort

Wenn du mehrere Schlüssel hast, stelle sicher, dass du den richtigen überprüfst. Das Protokoll ist pro Schlüssel, und ein leeres Protokoll bedeutet lediglich, dass genau dieser Schlüssel nicht verwendet wurde.

Schritt 2: Treffen die Aufrufe den richtigen Pfad und die richtige Methode?

Vergleiche die Spalten „Pfad“ und „Methode“ mit deinen Erwartungen:

• Wenn du nur „GET“ siehst, liest die Integration ausschließlich Daten aus. Sollte sie auch etwas ändern, fehlen „POST“-Aufrufe (Erstellen) oder „PUT“-Aufrufe (Aktualisieren).
• Wenn du einen Pfad siehst, der in der API nicht vorhanden ist, ist der Endpunkt in der Konfiguration falsch geschrieben. Ein solcher Aufruf wird mit einem 404 beantwortet, was du jedoch nur am Pfad erkennen kannst, da das Protokoll keine Statuscodes anzeigt
• Wenn du „product“ siehst, wo du „product/123“ erwartet hast, ruft die Integration die gesamte Liste statt des einzelnen Produkts ab. Das ist nicht unbedingt ein Fehler, aber oft die Erklärung für einen hohen Verbrauch

Sortiere nach Pfad, um identische Aufrufe zusammenzufassen. So fällt sofort ins Auge, wenn ein einzelner Endpunkt für den Großteil der Aufrufe verantwortlich ist.

Schritt 3: Sendet die Integration die richtigen Parameter?

Die Spalte „Parameter“ gibt Aufschluss darüber, wie die Integration in der Praxis eingerichtet ist. Typische Punkte, auf die du achten solltest:

• Ist ein „last_modified“-Parameter vorhanden? Fehlt dieser, ruft die Integration jedes Mal alles ab, anstatt nur die seit dem letzten Abruf geänderten Daten
• Sind „limit“ und „offset“ angegeben, und zählt der „offset“ wie erwartet hoch? Bleibt er bei 0, bleibt die Integration auf der ersten Seite hängen und sieht den Rest deiner Daten nie
• Sind Filter enthalten, mit denen du nicht gerechnet hast, z. B. eine Suche oder eine Einschränkung der Felder?

Denke daran, dass der Inhalt von POST- und PUT-Aufrufen nicht gespeichert wird. Das Protokoll kann dir zeigen, dass eine Aktualisierung für Produkt 123 gesendet wurde, aber nicht, welche Werte darin enthalten waren.

Schritt 4: Ist es der richtige Absender?

Die Spalten „IP“ und „User-Agent“ zeigen an, wer den Schlüssel verwendet. Wenn du den Absender nicht erkennst, wird der Schlüssel von etwas anderem verwendet, als du denkst, z. B. von einem alten Testskript, einem früheren Lieferanten oder einem Kollegen, der den Schlüssel kopiert hat. Klicken Sie auf die IP-Adresse, um alle Aktivitäten dieses Absenders anzuzeigen.

Hier kannst du auch feststellen, ob sich zwei Systeme denselben Schlüssel teilen. Wenn du zwei verschiedene User-Agents für denselben Schlüssel siehst, gibt es zwei Systeme, die ihn nutzen, und dann kannst du weder deren Nutzung voneinander trennen noch das eine System deaktivieren, ohne das andere zu beeinträchtigen. Erstelle für jedes System einen eigenen Schlüssel.

Schritt 5: Wie oft ruft es an?

Sortiere nach „Zeitpunkt“ und schau dir den Abstand zwischen den Aufrufen an. Läuft die Synchronisierung alle fünf Minuten, obwohl sie eigentlich einmal pro Stunde laufen sollte? Gibt es jede Nacht einen großen Cluster von Aufrufen? Filtern Sie nach einer Methode oder suchen Sie nach einem Endpunkt und nutzen Sie die Zahl oben auf der Seite als Zähler.

Gibt es deutlich mehr Aufrufe als erwartet, ist dies oft der Grund dafür, dass die Integration das Tageslimit erreicht und einen 429-Fehler erhält. Mehr dazu erfährst du im Artikel über API-Schlüssel und Tageslimits.

Für Entwickler

Der Eintrag wird in dem Moment geschrieben, in dem der Schlüssel autorisiert wird, also bevor der Aufruf weitergeleitet wird und bevor das Tageslimit überprüft wird. Deshalb tauchen die Fehlercodes 403, 404, 405 und 429 im Protokoll auf, während 401 niemals erscheint. Ein leeres Protokoll ist mit anderen Worten an sich schon ein nützliches Signal: Der Aufruf ist entweder nicht angekommen oder wurde bei der Authentifizierung abgelehnt.

Da weder der Statuscode noch der Request-Body oder der Response-Body gespeichert werden, ist es ratsam, Zeitstempel, Methode, Pfad und Abfragezeichenfolge in Ihrem eigenen Client zu protokollieren, damit die beiden Protokolle miteinander abgeglichen werden können. Füge deinen Aufrufen außerdem einen festen, wiedererkennbaren User-Agent hinzu. Das ist das einzige Feld im Protokoll, das du selbst kontrollierst, und es erleichtert es, dein eigenes Skript von Integrationen von Drittanbietern zu unterscheiden, auch wenn diese denselben Shop nutzen.

Das solltest du bereithalten, wenn du dich an den Support wendest

Wenn wir uns das Problem ansehen sollen, geht es viel schneller, wenn du Folgendes parat hast:

• Den Namen des Schlüssels, den die Integration verwendet. Sende den Namen, nicht den Schlüssel selbst
• Den genauen Zeitpunkt eines fehlgeschlagenen Aufrufs. Halte die Maus über den Zeitpunkt im Protokoll, um Datum und Uhrzeit auf die Sekunde genau anzuzeigen
• Pfad und Methode des Aufrufs
• Was du erwartet hast und was stattdessen passiert ist

Häufig gestellte Fragen

Ich bin kein Techniker. Brauche ich das API-Protokoll überhaupt?

Nicht im Alltag. Das Protokoll ist ein Tool zur Fehlersuche, nichts, was du ständig im Auge behalten musst. Aber wofür du es immer nutzen kannst, ist zu überprüfen, ob gerade überhaupt Aufrufe von einer Integration eingehen. Wenn beispielsweise deine Versandlösung ins Stocken gerät, öffne das Protokoll für den entsprechenden Schlüssel und schau dir die oberste Zeile an. Steht dort „vor 2 Tagen“, dann ist der externe Dienst ausgefallen, nicht dein Shop. Diese Antwort reicht oft schon aus, um weiterzukommen.

Warum kann ich die Antwortcodes im Protokoll nicht sehen?

Das Protokoll speichert den eingehenden Aufruf, nicht die Antwort. Wenn du anhand von Fehlercodes eine Fehlersuche durchführen möchtest, musst du die Antwort in deinem eigenen Client protokollieren. Das Protokoll dient dazu, zu bestätigen, dass der Aufruf angekommen ist, und um zu sehen, welchen Pfad und welche Methode er getroffen hat und welche Parameter er mitgebracht hat. Eine Ausnahme ist wissenswert: Aufrufe, die mit dem Status 401 abgelehnt werden, tauchen im Protokoll überhaupt nicht auf. Ein völlig leeres Protokoll ist daher an sich schon ein deutlicher Hinweis darauf, dass der Schlüssel falsch ist oder gelöscht wurde.

Unser Lagersystem hat die Aktualisierung eingestellt. Was muss ich als Erstes tun?

Gehen Sie zu „Integrationen“ → „API-Zugriff“, klicken Sie bei dem Schlüssel des Lagersystems auf „Abmelden“ und sehen Sie sich die oberste Zeile an. Steht dort „vor 3 Tagen“, ist das System vor drei Tagen ausgefallen, und der Fehler liegt beim Lagersystem. Steht dort „vor 5 Minuten“, werden die Aufrufe angezeigt, und dann musst du zu den Spalten „Pfad“ und „Parameter“ weitergehen. Notiere dir den Zeitpunkt, bevor du den Anbieter kontaktierst, denn das ist das Erste, wonach er fragen wird.

Kann ich ein Gesamtprotokoll für alle Schlüssel im Shop einsehen?

Nein, das Protokoll wird pro Schlüssel angezeigt. Genau deshalb ist es empfehlenswert, pro Integration einen Schlüssel mit einem aussagekräftigen Namen anzulegen, z. B. „Lagersystem“ oder „Preiswächter“. Auf der Seite „API-Zugriff“ kannst du nach „Zuletzt verwendet“ sortieren und schnell erkennen, welche Schlüssel tatsächlich aktiv sind, und die Spalte „Tägliches Limit“ zeigt die Nutzung und das Limit pro Schlüssel an. Wenn Sie den Verbrauch über verschiedene Bereiche hinweg vergleichen möchten, ist die Übersicht der richtige Ort dafür, nicht das Protokoll.

Unser Buchhaltungssystem hat einen Auftrag falsch verbucht. Kann ich im Protokoll sehen, was gesendet wurde?

Sie können sehen, dass ein Aufruf gesendet wurde, wann, mit welcher Methode und an welchen Pfad, z. B. ein PUT an order/3658. Der eigentliche Inhalt wird nicht gespeichert, sodass Sie nicht sehen können, welche Beträge oder Konten damit verbunden waren. Dazu benötigst du den Beleg oder das Protokoll im Finanzsystem. Das Protokoll kann hingegen den Zeitpunkt ganz genau bestimmen, und das reicht in der Regel aus, um die richtige Buchung auf der anderen Seite zu finden.

Das Protokoll zeigt die ganze Nacht über alle fünf Minuten einen Aufruf an. Ist das ein Problem?

An sich nicht, aber es lohnt sich, das einmal durchzurechnen. Ein Aufruf alle fünf Minuten ergibt knapp 300 Aufrufe pro Tag, und wenn die Integration mehrere Seiten auf einmal abruft, vervielfacht sich diese Zahl. Das fließt in das tägliche Limit des Schlüssels ein. Schauen Sie sich die Spalte „Parameter“ an: Wenn kein „load_modified“ enthalten ist, ruft die Integration jedes Mal das gesamte Verzeichnis ab, und dann sind die allermeisten Aufrufe verschwendet. Bitten Sie den Anbieter, so umzustellen, dass nur Änderungen seit dem letzten Abruf abgerufen werden.

Kann ich das API-Protokoll als Nachweis gegenüber meinem Steuerberater verwenden?

Nein. Die Einträge werden nach acht Wochen automatisch gelöscht, und das Protokoll enthält weder Beträge noch den Inhalt der Aufrufe. Sie dokumentiert, dass ein System deinen Shop zu einem bestimmten Zeitpunkt aufgerufen hat, nicht aber, was dabei ausgetauscht wurde. Für die Buchhaltungsdokumentation musst du die Bestellungen im Shop und die Belege im Buchhaltungssystem verwenden.

Unser Preiswächter gibt an, die Preise stündlich zu aktualisieren, aber die Preise ändern sich nicht. Wie kann ich das überprüfen?

Öffne das Protokoll für den Schlüssel des Preiswächters und klicke in der Spalte „Methode“ auf „PUT“, um nach der Methode zu filtern. Gibt es überhaupt keine PUT-Aufrufe, liest der Dienst nur und schreibt nicht, unabhängig davon, was in seiner Konfiguration steht. Gibt es stündlich „PUT“-Aufrufe für Produktpfade, werden die Aktualisierungen angezeigt. Überprüfe zunächst, ob der Schlüssel auf „Nur Lesen“ gesetzt ist, denn dann werden Schreibvorgänge mit einem 403-Fehler abgelehnt, auch wenn die Aufrufe im Protokoll stehen. Ist der Schlüssel richtig eingestellt, musst du prüfen, ob die richtigen Produkte betroffen sind oder ob die Preise anschließend durch etwas anderes überschrieben werden.

Benötigen Sie Hilfe bei der API-Integration? Kontaktieren Sie uns unter support@shoporama.dk.