Amazon SP API - Erfahrungsaustausch

Smalltalk / Allgemeines
1

Guten Morgen,

gibt es hier Leute, die aktiv mit der SP API arbeiten und sich austauschen wollen? Die Dokumentation ist zwar umfangreich, aber trotzdem lückenhaft. Jetzt gehen ich mal davon aus, wie es bei Plenty auch war, dass irgendwer das Problem, das ich aktuell habe schonmal hatte und es gelöst hat oder einen Workaround gefunden hat oder andersrum.

Das Schwarmwissen nutzen :smiley:

Mein aktuelles Problem:

Ich finde keinen Report / Endpunkt, der mir zuverlässig die Produktkategorie ausgibt, die als Grundlage der Verkaufsgebühr dient.

Seller Central sagt Produkt ist ‚Gewerbe, Industrie & Wissenschaft‘, was 15% Gebühr unabhängig vom VK bedeutet.

Der Revenue Calculator sagt, die ASIN ist ‚Personal Health & Care‘ 15% Gebühr, ABER 8% wenn VK unter 10 EUR.

Die Spalte ‚Produktkategorie‘ in der Gebührenvorschau bzw. dem API Report ‚GET_FBA_ESTIMATED_FBA_FEES_TXT_DATA‘ weicht oft auch von der Gebühren-Kategtorie ab.

Die angezeigte geschätzte Gebühr deckt sich mit dem , was abgerechnet wird, passt aber oft nicht zur Info ‚product category‘.

Jetzt kann ich mir aus der berechneten Gebühr herleiten, welche Kategorie am wahrscheinlichsten angewendet wird, habe aber keinen echten IST-Wert.

Ich suche eine Option um sicher festzustellen, welche (Gebühren-)Kategorie aktuell hinter einem Artikel liegt, finde aber nichts.

Fee Preview: Zahlenwert aus ‚estimated-referral-fee-per-unit‘ passt, nomineller Wert aus ‚product-group‘ häufig nicht.

2

Hallo Sören,

folgende Antwort hat mir die KI CLaude Code ausgegeben.

Ich habe mit claude meine SP-API Anbindung bauen und die Anmeldung dafür machen lassen.

Ob Sie deine Frage jetzt konkret beantwortet weiß ich aber nicht.

Hier die Antwort:

Hi Sören,

kurz vorweg, weil das deine Kernfrage beantwortet: die Gebührenkategorie ist über
kein API-Feld abrufbar. Amazon exponiert sie nirgends als ID oder Enum. Was du
bekommst, ist immer nur der Betrag. Die „Produktkategorie“-Spalten, die du siehst,
stammen aus einer anderen Pipeline (Katalog-Klassifizierung / product group) als die
Gebühren-Engine — deshalb passen sie so oft nicht zusammen. Das ist kein Fehler bei
dir, das ist by design.

Deshalb dreht man das Problem um: nicht die Kategorie ermitteln und daraus die Gebühr
rechnen, sondern die Gebühr messen und daraus das Gebührenmodell ableiten.

WARUM DEINE DREI QUELLEN AUSEINANDERLAUFEN

  • Seller-Central-Kategorieanzeige = Katalogzuordnung (Browse Node / Produkttyp).
    Steuert die Gebühr nur indirekt.
  • GET_FBA_ESTIMATED_FBA_FEES_TXT_DATA, Spalte product-group = Alt-Attribut aus
    MWS-Zeiten, Snapshot, häufig veraltet. War nie als Gebührenkategorie gedacht.
  • Revenue Calculator / Fee Preview = die tatsächliche Gebühren-Engine. Der Zahlenwert
    stimmt, das Label daneben ist Deko.

DAS PRAKTIKABLE VORGEHEN
Product Fees API, getMyFeesEstimateForASIN (bzw. getMyFeesEstimates als Batch, bis 20
Items pro Call). Entscheidend: Preis mitgeben, denn genau daran hängen die Staffeln.

  1. Pro ASIN 2-3 Probepreise schicken, z. B. 5,00 / 9,99 / 25,00 EUR. IsAmazonFulfilled
    korrekt setzen, sonst mischen sich FBA-Gebühren rein. Versandkosten so mitgeben wie
    im Echtbetrieb - die Provision wird auf den Gesamtpreis inkl. Versand berechnet.
  2. Aus der FeeDetailList nur FeeType = ReferralFee nehmen: FinalFee / Listenpreis =
    effektiver Satz.
  3. Springt der Satz zwischen zwei Preispunkten (bei dir 8 % → 15 %), die Schwelle per
    Binärsuche exakt bestimmen. Zwischen 1 und 100 EUR bist du mit gut einem Dutzend
    Calls centgenau; praktisch reichen 6-8, weil die Schwellen auf glatten Beträgen
    liegen.
  4. Ergebnis als Gebührenprofil je ASIN persistieren:
    {satz_unter, schwelle, satz_ueber, mindestgebuehr} - Mindestprovision DE aktuell
    0,30 EUR je Artikel. Danach rechnest du offline, ohne für jede Kalkulation die API
    zu fragen.
  5. Monatlich neu ziehen. Amazon ändert Zuordnungen still und ohne Ankündigung.

DEN ECHTEN IST-WERT BEKOMMST DU NUR HINTERHER
GET_V2_SETTLEMENT_REPORT_DATA_FLAT_FILE_V2, Posting-Typ „Commission“ je
Bestellposition. Das ist der einzige Wert, den Amazon dir tatsächlich abgerechnet hat.
Den nachts gegen das gespeicherte Profil abgleichen, Abweichung > 1 Cent gibt ein
Ticket. So fällt eine Umkategorisierung innerhalb von Tagen auf statt im
Quartalsabschluss.

WENN DIE KATEGORIE FALSCH IST
Dann hilft nur der Katalogweg, nicht die API: item_type_keyword bzw.
Browse-Node-Zuordnung korrigieren oder Case im Seller Central aufmachen („Artikel ist
der falschen Gebührenkategorie zugeordnet“, mit ASIN, gewünschter Kategorie und
Begründung). Die Gebühren-Engine folgt der Katalogzuordnung, nur zeitversetzt und
nicht 1:1 sichtbar.

ZWEI FALLSTRICKE

  • Die Rate Limits der Product Fees API sind knapp (Größenordnung 1 Request/Sekunde,
    Batch noch weniger). Die real geltenden Werte stehen im Response-Header
    x-amzn-RateLimit-Limit - danach steuern, nicht nach der Doku.
  • Für einzelne ASINs kommt FeesEstimateError statt eines Betrags zurück (meist fehlende oder gesperrte Katalogdaten). Dafür brauchst du einen Fallback, sonst reißt dir der Batch mittendrin ab.

Kurz: Einen abfragbaren IST-Wert für die Kategorie gibt es nicht. Der einzige
belastbare IST-Wert ist der abgerechnete Betrag im Settlement - und der reicht, wenn du
das Gebührenmodell daraus ableitest statt umgekehrt.

MfG Christian

3

Guten Morgen,

nicht ganz die Antwort, auf die ich gehofft hatte, aber ein Ansatz, den ich übersehen hatte. :+1:

Falls für dich relevant:

Die abgerechneten Gebühren bekommst du auch über die Finances API für einen beliebigen Zeitraum, sogar von heute, und nicht wie beim GET_V2_SETTLEMENT_REPORT_DATA_FLAT_FILE_V2 für den Auszahlungszeitraum.

4

Hier die Antwort von Claude an Dich:

Danke, guter Punkt — die Finances API ist für den Zweck tatsächlich die bessere Quelle,
weil sie nicht am Auszahlungszeitraum hängt.

Zwei Dinge, die ich mir dabei angewöhnt habe: ganz frische Beträge sind noch vorläufig
(in der 2024-06-19-Variante stehen sie als DEFERRED und werden erst später RELEASED),
und Retouren buchen verzögert gegen die Provision. Für die laufende Kalkulation nehme
ich deshalb Finances, für den verbindlichen Abgleich weiter das Settlement — das ist
das, was am Ende wirklich ausgezahlt wird.

MfG Christian

5

Das zeigt dann auch die Schwächen von Claude bzw. LLMs.
Deferred und Released sind schlicht Ausdruck, ob die Zahlung für die verfügbar ist oder nicht, der Betrag ändert sich nicht mehr. Bzw. Korrekturen laufen als separate Transaktion rein.

Das Retouren-Problem hat der Settlement Report auch. Zwischen Zahlung und Erstattungen können ja theoretisch Jahre liegen (unsere älteste Erstattung war, glaube ich, bald 4 Jahre nach dem eigentlichen Kauf, natürlich vom Amazon Kundensupport ohne Rücksprache :smiley: ). Zahlung und Erstattung sind auch im Settlement 2 Zeilen.

Mich interessiert ja was für einen Verkauf abgerechnet wird und ob das Korrekt ist.
Wenn du dich auf den Settlement Report verlässt, sind mögliche falsche Gebühren schon wochenlang aufgelaufen. Je höher der Betrag ist, desto mehr wehrt sich Amazon eine Erstattung zu leisten.

Oder anders: Claude sollte nicht federführend sein, was verwendet wird und was welche Relevanz hat.

Der Ping an die getMyFeesEstimateForASIN hat im übrigen funktioniert, in einer wesentlich kürzeren Version, weil die Preisschwelle ja klar definiert ist.