Wenn Sie nach Amazon-Odoo-Connector oder Amazon SP-API Odoo suchen, lautet die kurze Antwort: Es braucht drei Zugangsdaten, die nicht von derselben Stelle kommen (eine SP-API-Anwendung, registriert von einem Entwicklerprofil mit genehmigten Rollen, die LWA-Schlüssel dieser Anwendung und ein Refresh Token pro Verkäufer, der sie autorisiert), dazu die Marketplace-ID und den regionalen Endpunkt. Und eine Architekturentscheidung: Die Limits sind Token-Buckets pro Operation, also arbeitet der Connector mit Queue und Backoff statt mit Schleifen.
Alles Folgende wurde am 13. September 2026 in der offiziellen SP-API-Dokumentation und im Code unseres Amazon-Seller-Connectors für Odoo geprüft, veröffentlicht auf den Branches 19.0, 18.0 und 17.0, mit 786 eigenen Tests auf dem Odoo-19-Branch und jeweils 685 auf den beiden anderen.
Eine gute Amazon-Odoo-Integration misst sich nicht daran, dass die Zugangsdaten eingerichtet sind, sondern daran, ob sie manuelle Arbeit reduziert, Bestandsfehler vermeidet und Nachvollziehbarkeit liefert, wenn Amazon mit 429 antwortet.
Was ein Amazon-Odoo-Connector lösen muss
- Zuverlässiger Bestellimport und Bestandsreservierung.
- Zuordnung von SKU, Varianten und Listings ohne Duplikate.
- Synchronisierung von Status, Tracking und Bestätigungen.
- Verwaltung von Preisen, Störfällen und Fehlerfällen.
- Behandlung von FBA, wenn es Teil des Betriebs ist.
- Logs und Wiederholungsversuche, wenn Amazon oder die interne Queue ausfällt.
Jede Zeile kommt durch eine andere Tür (/orders/v0, /listings/2021-08-01, /feeds/2021-06-30, /reports/2021-06-30), und jede Tür hat ihr eigenes Limit.
Welche Zugangsdaten SP-API verlangt und wer sie ausstellt
1. Die Anwendung. SP-API öffnet sich nicht mit dem Benutzer von Seller Central, sondern mit einer Anwendung, die im Solution Provider Portal von einem genehmigten Entwicklerprofil registriert wurde. Bei der Registrierung wählt man Rollen (Amazon dokumentiert achtzehn), und nur bereits genehmigte stehen zur Auswahl. Vier sind eingeschränkt, weil sie personenbezogene Daten berühren, darunter Direct-to-Consumer Shipping. Und die Rolle allein genügt nicht: Die Lieferadresse wird mit einem restricted data token angefordert (POST /tokens/2021-03-01/restrictedDataToken).
2. Die LWA-Schlüssel. Aus der Anwendung ergeben sich eine client_id und ein client_secret von Login with Amazon. Das Secret läuft nach 180 Tagen ab: Amazon warnt 90 Tage vorher, und das alte gilt noch sieben Tage weiter. Danach schlagen die Aufrufe fehl, ohne dass jemand etwas angefasst hat, und das Symptom (invalid_client mitten in der Nacht) hat mit seiner Ursache nichts zu tun; deshalb speichert der Connector dieses Datum und warnt per täglichem Cron.
3. Das Refresh Token des Verkäufers. Es ist das Einzige, das nicht Sie ausfüllen: Der Verkäufer erzeugt es, indem er die App unter sellercentral…/apps/authorize/consent autorisiert, mit der application_id und einem eigenen state; solange die App im Entwurf ist, kommt &version=beta dazu, und beim Veröffentlichen muss es entfernt werden. Amazon liefert es an Ihre Redirect-URI mit einem spapi_oauth_code zurück, der innerhalb von fünf Minuten bei https://api.amazon.com/auth/o2/token eingelöst werden muss: Heraus kommen ein access_token, das nach einer Stunde abläuft, und das refresh_token.
4. Marketplace und Region. Ein Konto ist kein Land: Es ist eine marketplace id (Spanien A1RKKUPIHCS9HS, Frankreich A13V1IB3VIYZZH), die auf einen regionalen Endpunkt zeigt, in Europa https://sellingpartnerapi-eu.amazon.com. Unser Connector bringt die 23 Marketplaces als Daten mit, und jedes Konto verweist auf genau einen, damit Bestand, Steuern und Kanal aus der richtigen Quelle stammen.

Ratenlimits: warum der Connector eine Queue braucht
Amazon verteilt den Datenverkehr mit einem Token-Bucket: Jede Operation hat eine Rate (Tokens pro Sekunde) und einen Burst (Kapazität), und jede Anfrage verbraucht ein Token. Ist der Bucket leer, kommt ein 429, den die Dokumentation als wiederholbar bezeichnet, und (wenn verfügbar, was nicht immer der Fall ist) kehrt der Header x-amzn-RateLimit-Limit mit dem Limit Ihres Paares aus Verkäufer und Anwendung zurück. Die Limits gelten pro Operation, und die in der Tabelle sind Standardwerte, die Amazon für Verkäufer mit mehr Volumen erhöhen kann.
| Operation | Rate (Anfr./s) | Burst | In der Praxis |
|---|---|---|---|
| getOrders | 0,0167 | 20 | Eine Liste pro Minute: Alle zehn Sekunden abzufragen endet in 429. |
| getOrder / getOrderItems | 0,5 | 30 | Das Detail ist viel günstiger als die Liste. |
| confirmShipment | 2 | 10 | Das Risiko ist nicht das Kontingent, sondern der Verlust von Sendungen. |
| createReport | 0,0167 | 15 | Ein Bericht pro Minute: anfordern und warten. |
| getReportDocument | 0,0167 | 15 | Das Herunterladen teilt sich das Kontingent mit dem Erstellen. |
| createFeed | 0,0083 | 15 | Einer alle zwei Minuten: wird eingeplant. |
| putListingsItem | 5 | 10 | Bei wenigen Änderungen schlägt es den Feed. |
Diese Tabelle erklärt die Architektur. Weil getOrders bei einer Anfrage pro Minute liegt, werden Bestellungen mit einem Wasserzeichen (LastUpdatedAfter) und Paginierung über NextToken von einem Cron alle fünfzehn Minuten gelesen, nicht per Schaltfläche. Weil man auf Berichte warten muss, lautet der Zyklus erstellen, abfragen, herunterladen: Wir fragen bis zu zwölfmal alle zehn Sekunden ab. Und weil Berichtsaufrufe sich einen Bucket teilen, schreibt der Connector bei einem 429 eine gemeinsame Abkühlphase von 90 Sekunden, und der FBA-Bestand fällt auf die Live-API zurück.
Die Wiederholung steckt in einer einzigen Funktion: 429 sowie 500, 502, 503 und 504 werden wiederholt, Retry-After wird beachtet, und wenn er fehlt, wartet ein exponentieller Backoff ab 1,5 Sekunden mit zufälligem Rauschen, damit zwei Crons nicht gleichzeitig zurückkehren. Scheitert auch der letzte Versuch, trägt der Fehler die Retry-After, den Kontingent-Header und den Pfad in sich: Das Log sagt, welches Kontingent erschöpft war, nicht «Fehler bei der Synchronisierung».
Daraus folgt die Regel: Was schreibt, geht in eine Queue mit Idempotenzschlüssel; was liest, arbeitet mit Wasserzeichen. Die Versandbestätigung kann als «ausstehend» in der Queue bleiben, und dann sendet nur ein Cron alle fünf Minuten, der höchstens 200 Lieferscheine der letzten drei Tage nimmt, mit einer Sperre pro Lieferschein, die verhindert, dass dasselbe Tracking zweimal gesendet wird. Preise und Bestand haben jede Minute eine eigene Queue; schlägt ein Schreibvorgang fehl, wiederholt ihn eine weitere Queue alle 180 Sekunden, höchstens zwanzigmal pro SKU.
Warum Amazon Vorgänge stört, wenn nicht Odoo führt
Wenn der Bestand aus mehreren Quellen kommt oder das Tracking außerhalb des ERP verwaltet wird, folgen Störfälle: nicht zugeordnete Bestellungen, inkonsistenter Bestand und teurerer Kundendienst. Mit den Limits vor Augen sieht man, warum der Kanal, der den Bestand veröffentlicht, nur einer sein darf: Ihn doppelt zu veröffentlichen kostet das doppelte Kontingent. Wir vertiefen das in Echtzeit-Bestand auf Marketplaces und in auf mehreren Marketplaces mit einem einzigen Odoo verkaufen.
Häufige Fehler bei Amazon SP-API in Odoo
Fast alle Fehler, die wir sehen, stammen von diesen drei Zugangsdaten, nicht vom Code: eine Redirect-URI, die auf ein anderes Odoo zeigt, sodass die Rückkehr des Verkäufers auf einem Bildschirm endet, der sagt, dass ihn niemand erwartet hat; eine Autorisierung mit version=beta, obwohl die App bereits veröffentlicht ist; das abgelaufene LWA-Secret; die eingeschränkte Rolle ohne Genehmigung, die keinen klaren Fehler liefert, sondern leere Adressen; und die 429-Schleife, wenn jemand von Hand wiederholt, während auch der Cron wiederholt.
Jeder hat ein Symptom, das seiner Ursache nicht ähnelt, deshalb haben wir sie mit ihrer Diagnose in Amazon SP-API und Odoo: häufige Fehler und wie Sie sie vermeiden zusammengestellt. Wenn es bei Ihnen um die Einführung geht, finden Sie den Ablauf in so integrieren Sie Amazon mit Odoo 19.
Beginnen Sie mit dem, was am meisten schmerzt
Mit den Limits vor Augen gibt es eine sinnvolle Reihenfolge: zuerst Bestellungen, Bestand und Tracking, die drei Aufrufe, die das Lager tragen; danach Listings, Preise, FBA oder Retouren, wenn das Geschäft es verlangt. Berichte kommen zuletzt: Sie sind nicht schwierig, sie verbrauchen das langsame Kontingent.
Was Sie vor dem Kauf fragen sollten
- Welche Abläufe heute unterstützt werden und über welche API jeder läuft.
- Ob die Verbindung Ihre Anwendung oder die des Anbieters nutzt und wer das LWA-Secret erneuert.
- Was bei einem 429 passiert: Wird wiederholt, in die Queue gestellt, Retry-After beachtet, eine Spur hinterlassen?
- Wie FBA, Retouren und Adressen mit personenbezogenen Daten behandelt werden.
- Ob bei zweimaliger Bestätigung derselben Sendung das Tracking zweimal gesendet wird.
- Ob der Anbieter einführt oder nur Lizenzen verkauft und auf welchen Versionen er das Modul pflegt.
Wenn die Integration nicht mit Amazon, sondern mit Ihrer eigenen Verwaltungssoftware erfolgt, ist der Ansatz derselbe, und wir beschreiben ihn in Odoo-Connector für Ihre Software; den Katalog finden Sie unter Module und die Übersicht nach Problem unter Lösungen.
Häufige Fragen
Muss ich Amazon-Entwickler sein, um Odoo mit SP-API zu verbinden?
Jemand muss es sein, aber nicht unbedingt Sie: Die Anwendung registriert ein genehmigtes Entwicklerprofil, das die Client-ID und das Secret erhält. Als Verkäufer können Sie Ihre eigene registrieren oder die Ihres Anbieters autorisieren und nur Ihr Refresh Token behalten.
Warum dauern Amazon-Berichte in Odoo so lange?
Weil es keine Abfrage ist: Man fordert sie mit createReport an, Amazon erzeugt sie in der eigenen Queue, man fragt getReport bis DONE ab und lädt sie dann mit getReportDocument herunter. Erstellen und Herunterladen sind auf 0,0167 Anfragen pro Sekunde begrenzt, jeweils eine pro Minute.
Sollte ein Amazon-Odoo-Connector FBA verwalten?
Wenn Sie mit FBA arbeiten, ja: Der Bestand darf nicht geteilt bleiben. Beachten Sie, dass der maßgebliche Bestand per Bericht mit dem langsamen Kontingent eintrifft, daher empfiehlt sich als Rückfall ein Live-Abruf.
Können Amazon und Odoo Tracking und Status austauschen?
Ja. Die Versandbestätigung erlaubt zwei Anfragen pro Sekunde, das Risiko ist also nicht das Kontingent, sondern der Verlust von Sendungen: Verlangen Sie eine Queue mit Wiederholung und eine Sperre, die verhindert, dass dasselbe Tracking zweimal gesendet wird.
Kann man nur mit Bestellungen und Bestand beginnen?
Ja. Viele Einführungen beginnen so und erweitern später auf Preise, Listings, FBA oder Retouren. Das ist außerdem die Reihenfolge, die am wenigsten Kontingent verbraucht.
Was unterscheidet einen seriösen Connector von einem einfachen?
Dass ein 429 vom allgemeinen Fehler unterschieden wird und das Kontingent in der Meldung trägt, dass Schreibvorgänge mit Idempotenz in eine Queue gehen, dass das LWA-Secret vor dem Ablauf warnt und dass Tests es belegen.
Nützliche Links bei FlexigoTech
Was wir dazu tun
Möchten Sie prüfen, ob Amazon in Odoo zentralisiert werden sollte?
Wir prüfen SKUs, Bestand, Logistik und Kanäle, um Ihnen zu sagen, wo Sie beginnen sollten, ohne die Einführung zu überdimensionieren, und welche SP-API-Zugangsdaten Sie zuerst beantragen müssen. Schreiben Sie an comercial@flexigobe.com oder rufen Sie uns unter +34 616 809 504 an.

