OTTO API-Limits 2026: Fehlercodes bei Massen-Updates vermeiden

Die kurze Antwort: OTTO Market begrenzt API-Zugriffe pro Partner-ID auf 20 Anfragen pro Sekunde beziehungsweise 1.200 Anfragen pro Minute, einzelne Endpunkte wie die Token-Vergabe sogar auf 10 Anfragen pro Sekunde je IP-Adresse. Wer diese Grenzwerte bei Massen-Updates von Preisen, Beständen oder Produktdaten überschreitet, bekommt den HTTP-Fehlercode 429 "Too Many Requests" zurück — und im schlimmsten Fall bleiben Preisänderungen oder Lagerbestände unvollständig im System hängen, während der Shop längst weiterverkauft.

Diese Werte stehen so in der offiziellen OTTO-Market-API-Dokumentation und sind kein Geheimnis, werden aber von vielen Händlern und Agenturen erst entdeckt, wenn ein Massen-Update mitten im Tagesgeschäft abbricht. Für Sie als Händler mit laufendem Sortiment auf OTTO Market bedeutet das: Ihre Anbindung — ob Eigenentwicklung, ERP-Konnektor oder Channel-Manager — muss Rate-Limits von Anfang an einplanen, nicht erst reparieren, wenn der erste Fehlerbericht auf dem Tisch liegt.

In diesem Beitrag zeigen wir, wie das Rate-Limiting bei OTTO Market technisch funktioniert, welche Fehlerbilder typisch sind, und wie Sie Ihre Automatisierung so aufsetzen, dass Massen-Updates zuverlässig durchlaufen. AMZ+ Consulting betreut OTTO-Händler in DACH bei genau solchen technischen Anbindungsfragen — praxisnah und ohne Umwege über den Support.

Warum Rate-Limiting bei Massen-Updates zum operativen Risiko wird

Ein Massen-Update betrifft selten nur ein paar Artikel. Saisonale Sortimentswechsel, eine Preisrunde vor einer Rabattaktion oder ein Bestandsabgleich nach der Inventur erzeugen schnell mehrere Tausend einzelne Datensätze, die in kurzer Zeit an die OTTO-API übertragen werden sollen.

Genau hier liegt das Problem. Wenn Ihre Anbindung zu viele Anfragen gleichzeitig oder zu dicht getaktet sendet, greift die Drosselung von OTTO Market — unabhängig davon, ob Sie über die Partner-Connect-API, die Marketing-API oder einen CSV-Massenupload arbeiten. Die Folge ist kein sauberer Stopp, sondern ein teilweise durchlaufenes Update.

Das operative Risiko dahinter ist real und lässt sich in drei Kategorien fassen.

Erstens: veraltete Preise im Live-Betrieb. Wenn nur ein Teil Ihrer Preisänderungen durchkommt, verkaufen Sie einen Teil des Sortiments zu alten Konditionen — bei einer Preiserhöhung ein direkter Margenverlust, bei einer geplanten Rabattaktion ein inkonsistentes Kundenerlebnis.

Zweitens: veraltete Bestände und Verkauf trotz Ausverkauf. Bricht ein Bestands-Update ab, bleiben einzelne SKUs mit falschem Lagerstand online. Das führt zu Stornierungen, verärgerten Kunden und im wiederholten Fall zu einer schlechteren Verkäuferbewertung bei OTTO Market.

Drittens: unvollständige Produktdatenpflege. Gerade bei saisonalen Sortimentswechseln — etwa dem Umstellen ganzer Kategorien auf neue Attribute oder Bilder — bleibt bei einem abgebrochenen Update ein Teil der Artikel im alten Zustand, während der Rest bereits aktualisiert ist. Für Kunden wirkt das inkonsistent, für Sie ist es oft schwer nachzuvollziehen, welche SKUs betroffen sind.

Das Tückische: OTTO Market kommuniziert eine Drosselung nicht proaktiv. Sie bemerken das Problem erst am Fehlercode selbst — wenn Ihr System nicht sauber protokolliert, unter Umständen erst Tage später, wenn ein Kunde sich über einen falschen Preis oder eine falsche Verfügbarkeit meldet. Für Händler, die ihre OTTO-Anbindung über einen Channel-Manager oder die Partner-Connect-API betreiben, ist ein sauberes Fehlerhandling deshalb kein optionales Feature, sondern Grundvoraussetzung für den laufenden Betrieb.

Für Agenturen und Händler mit mehreren OTTO-Konten kommt eine weitere Ebene hinzu: Wird ein API-Zugang für mehrere Mandanten oder Marken gleichzeitig genutzt, summieren sich die Anfragen aller Mandanten auf dasselbe Limit. Ein Massen-Update für Mandant A kann dann unbemerkt das Kontingent belasten, das eigentlich für ein zeitkritisches Update von Mandant B gedacht war. Wer mehrere Konten über dieselbe technische Anbindung betreut, sollte deshalb von Anfang an eine zentrale Übersicht darüber haben, welcher Prozess wann wie viele Anfragen sendet.

Die dokumentierten OTTO-API-Grenzwerte und typische Fehlerbilder

OTTO Market veröffentlicht die zentralen Rate-Limits in der eigenen API-Dokumentation. Grundsätzlich gilt: authentifizierte API-Aufrufe sind pro Partner auf 1.200 Anfragen pro Minute begrenzt, was rechnerisch etwa 20 Anfragen pro Sekunde entspricht. Für einzelne Endpunkte gelten abweichende, teils niedrigere Grenzwerte — etwa für die Token-Vergabe unter /v1/token, die auf 10 Anfragen pro Sekunde je IP-Adresse begrenzt ist.

Wichtig für die Praxis: Die Drosselung erfolgt pro Partner-ID, nicht pro einzelnem Nutzer oder Prozess. Laufen bei Ihnen mehrere Systeme oder Skripte parallel auf denselben API-Zugang — zum Beispiel ein ERP-Export und gleichzeitig ein manuelles Korrektur-Skript —, teilen sich beide dasselbe Kontingent. Das ist eine häufige Ursache dafür, dass Drosselungen auftreten, obwohl das eigentliche Update-Volumen überschaubar wirkt.

Zusätzlich verarbeitet OTTO Market Massen-Anfragen an Produkt-Endpunkte asynchron: Eine Anfrage mit vielen Datensätzen erhält zunächst den Status 202 (Accepted) mit einer Prozess-ID zurück, die tatsächliche Verarbeitung läuft im Hintergrund weiter. Wer diesen Ablauf ignoriert und den Erfolg eines Updates allein am Status 202 festmacht, übersieht Fehler, die erst in der zweiten Verarbeitungsstufe entstehen — etwa wenn ein Produktdatensatz zwar technisch angenommen, aber inhaltlich von otto.de abgelehnt wird.

Typische Fehlerbilder, an denen Sie ein Rate-Limiting-Problem erkennen, sind:

• Der HTTP-Statuscode 429 in den Logs Ihrer Anbindung, meist gehäuft bei geplanten Massen-Jobs.
• Ein Update, das im eigenen System als "gesendet" markiert ist, im OTTO-Verkäuferportal aber nicht oder nur teilweise ankommt.
• Unregelmäßige Muster: An ruhigen Tagen läuft das Update durch, an Tagen mit paralleler Nutzung (z. B. gleichzeitiger manueller Preispflege) bricht es ab.
• Fehlende Fehlerrückmeldung, weil das eigene System 429-Antworten stillschweigend verwirft, statt sie zu protokollieren oder erneut zu versuchen.

Wenn Sie regelmäßig Daten über die OTTO Marketing-API oder per CSV-Massenupload einspielen, lohnt sich ein Blick in die eigenen Log-Dateien: Häufen sich 4xx-Fehler zu bestimmten Uhrzeiten, ist das ein klares Signal für eine zu aggressive Update-Taktung.

Wenn Ihnen diese Fehlerbilder bekannt vorkommen, Sie aber noch nicht genau wissen, an welcher Stelle Ihrer Anbindung das Problem entsteht, ist das ein guter Anlass für einen gemeinsamen Blick in Ihre Logs im kostenlosen Erstgespräch — oft lässt sich die Ursache innerhalb weniger Minuten eingrenzen.

In 8 Schritten Rate-Limit-Fehler diagnostizieren und beheben

So gehen Sie systematisch vor, wenn Massen-Updates bei OTTO Market unvollständig durchlaufen oder Sie präventiv vorbeugen wollen:

1. Fehlerprotokoll prüfen — sammeln Sie alle HTTP-Statuscodes Ihrer OTTO-API-Aufrufe der letzten Wochen und filtern Sie gezielt nach 429-Antworten.
2. Zeitmuster identifizieren — prüfen Sie, ob die Fehler zu bestimmten Uhrzeiten gehäuft auftreten, etwa während geplanter Massen-Jobs oder in Überschneidung mit anderen Prozessen auf demselben API-Zugang.
3. Parallele Zugriffe zusammenführen — stellen Sie sicher, dass nicht mehrere Systeme (ERP, Repricing-Tool, manuelle Skripte) unkoordiniert dieselbe Partner-ID belasten.
4. Retry-After-Header auswerten — implementieren Sie in Ihrer Anbindung die Auswertung des von OTTO zurückgegebenen Retry-After-Headers, statt feste Wartezeiten zu raten.
5. Exponentielles Backoff einbauen — bei einer 429-Antwort nicht sofort erneut senden, sondern die Wartezeit nach jedem Fehlversuch schrittweise verlängern (z. B. 2, 4, 8, 16 Sekunden).
6. Batching statt Einzelaufrufe nutzen — wo die API es zulässt, mehrere Datensätze in einer Anfrage bündeln, statt jede Preis- oder Bestandsänderung einzeln zu übertragen.
7. Update-Fenster außerhalb der Peak-Zeiten legen — große Sortimentswechsel und geplante Preisrunden bevorzugt in verkehrsärmeren Zeiten anstoßen und über den Tag verteilen, statt alles auf einmal zu senden.
8. Monitoring und Alerting einrichten — richten Sie eine automatische Benachrichtigung ein, sobald die 429-Fehlerquote einen Schwellenwert überschreitet, damit Sie reagieren, bevor Kunden es an falschen Preisen oder Beständen merken.

Diese Reihenfolge ist bewusst so aufgebaut: Erst verstehen Sie, wo das Problem herkommt, dann beheben Sie die technische Ursache, und zuletzt bauen Sie eine Frühwarnung ein, damit sich der Fehler nicht wiederholt.

Rechenbeispiel: Sortimentswechsel mit 5.000 Artikeln

Rechenbeispiel: Angenommen, Sie stellen zum Saisonwechsel 5.000 Artikel auf neue Preise und Bestände um und senden dafür pro Artikel zwei einzelne API-Aufrufe (einen für den Preis, einen für den Bestand) — macht 10.000 Anfragen insgesamt.

Wird das komplette Update ohne Pausen abgeschickt, wären bei einem Limit von 20 Anfragen pro Sekunde theoretisch rund 500 Sekunden nötig — reale Systeme erreichen dieses Tempo selten sauber, weil Verbindungsaufbau, Antwortzeiten und parallele Prozesse dazwischenfunken. Schon ein kurzzeitiger Push von mehreren Hundert Anfragen pro Sekunde, etwa weil ein Skript ohne Drosselung alle Datensätze "auf einmal" verschickt, reißt sofort in den 429-Bereich.

Nutzen Sie stattdessen Bulk-Endpunkte, die mehrere Datensätze in einer Anfrage bündeln, sinkt die Zahl der nötigen Aufrufe auf einen Bruchteil — bei einer sinnvollen Bündelung von beispielsweise 100 Artikeln pro Anfrage wären es nur noch rund 100 Aufrufe für den gesamten Bestand statt 10.000 Einzelanfragen. Das reduziert nicht nur das Risiko einer Drosselung erheblich, sondern beschleunigt das gesamte Update spürbar.

Dieses Beispiel ist hypothetisch und dient der Veranschaulichung der Größenordnung — die tatsächliche Zahl nötiger Anfragen hängt von Ihrem Sortiment, der genutzten API-Version und den verfügbaren Bulk-Endpunkten ab.

Was Sie jetzt tun können

Wenn Sie regelmäßig Massen-Updates auf OTTO Market fahren, lohnt sich ein kurzer Realitäts-Check Ihrer aktuellen Anbindung. Prüfen Sie zuerst, ob Ihr System 429-Fehler überhaupt protokolliert — viele Anbindungen verschlucken diese Antworten stillschweigend, weil niemand explizit danach gesucht hat.

Prüfen Sie danach, ob Ihre Prozesse bereits Batching und Backoff nutzen oder ob jede Preis- und Bestandsänderung als Einzelaufruf herausgeht. Gerade bei ERP-Anbindungen und älteren Channel-Manager-Konfigurationen ist Letzteres häufig der Fall, weil die Integration ursprünglich für ein kleineres Sortiment gebaut wurde.

Legen Sie außerdem fest, wer im Team dafür verantwortlich ist, wiederkehrende 429-Fehler zu überwachen. In der Praxis versanden solche Fehler oft, weil sie technisch zwar geloggt, aber organisatorisch niemandem konkret zugeordnet sind — bis ein Kunde sich über einen veralteten Preis beschwert und die Ursache erst rückwirkend rekonstruiert werden muss.

Wenn Sie mehrere Marktplätze parallel betreiben, ist zusätzlich ein Blick auf die Multichannel-Integration mit Ihrem ERP sinnvoll — oft laufen dort mehrere Update-Prozesse unkoordiniert über denselben API-Zugang. Für Bestands- und Preisentscheidungen über mehrere Marktplätze hinweg setzen wir intern zudem auf MarketplAIce, unsere eigene KI-Plattform, die Preis- und Bestandsupdates gebündelt und mit sauberem Fehlerhandling ausspielt.

Wenn Sie unsicher sind, ob Ihre aktuelle OTTO-Anbindung sauber mit Rate-Limits umgeht, oder wiederholt unerklärliche Lücken zwischen Ihrem System und dem OTTO-Verkäuferportal feststellen, klären wir das gemeinsam im kostenlosen Erstgespräch. Wir schauen uns Ihre Log-Daten an und sagen Ihnen ehrlich, ob eine technische Anpassung reicht oder ein grundlegenderer Umbau der Anbindung nötig ist.

FAQ: Häufige Fragen zu OTTO API-Rate-Limits

Wie hoch sind die Rate-Limits der OTTO Market API genau?

Laut offizieller OTTO-Dokumentation sind authentifizierte API-Aufrufe pro Partner grundsätzlich auf 1.200 Anfragen pro Minute begrenzt, was etwa 20 Anfragen pro Sekunde entspricht. Einzelne Endpunkte, etwa die Token-Vergabe, haben eigene, teils niedrigere Grenzwerte.

Was bedeutet der Fehlercode HTTP 429 bei OTTO Market konkret?

HTTP 429 "Too Many Requests" bedeutet, dass Sie das für Ihre Partner-ID geltende Anfragen-Limit in einem bestimmten Zeitraum überschritten haben. OTTO Market lehnt die überzählige Anfrage ab, verarbeitet sie also nicht — Sie müssen sie später erneut senden.

Woran erkenne ich, dass ein Massen-Update wegen Drosselung unvollständig war?

Am zuverlässigsten über ein Fehlerprotokoll, das 429-Antworten explizit erfasst. Zusätzlich hilft ein regelmäßiger Abgleich zwischen den in Ihrem System als "gesendet" markierten Datensätzen und dem tatsächlichen Stand im OTTO-Verkäuferportal.

Hilft es, die API-Aufrufe einfach langsamer zu senden?

Ja, in Kombination mit Batching ist das der wirksamste Hebel. Statt jede einzelne Preis- oder Bestandsänderung separat zu senden, bündeln Sie mehrere Datensätze in einer Anfrage und verteilen die Aufrufe über einen längeren Zeitraum, statt sie gebündelt auf einmal abzuschicken.

Was ist exponentielles Backoff und warum brauche ich das?

Exponentielles Backoff bedeutet, dass Sie nach einem 429-Fehler nicht sofort erneut senden, sondern die Wartezeit vor jedem weiteren Versuch schrittweise verlängern. Das verhindert, dass Ihr System die API bei einer bereits bestehenden Drosselung zusätzlich belastet und die Situation verschlimmert.

Gilt das Rate-Limit pro Nutzer oder pro gesamtem Unternehmen?

Die Drosselung erfolgt pro Partner-ID. Nutzen mehrere Systeme oder Mitarbeitende denselben API-Zugang parallel, teilen sie sich dasselbe Kontingent — das ist eine häufige, aber leicht übersehene Ursache für unerwartete 429-Fehler.

Sollte ich einen Channel-Manager nutzen, um Rate-Limits zu vermeiden?

Ein guter Channel-Manager übernimmt Batching und Backoff-Logik in der Regel bereits für Sie, was das Risiko reduziert. Garantiert ist das aber nicht bei jedem Anbieter — prüfen Sie im Zweifel konkret, wie der jeweilige Channel-Manager mit HTTP 429 umgeht, bevor Sie sich darauf verlassen.

Über den Autor

Jorginho Engelmeyer ist Geschäftsführer der AMZ+ Consulting GmbH und seit über 8 Jahren auf Amazon, Otto und Kaufland für Händler aktiv.

→ Kostenloses Erstgespräch buchen