eBay API 2026: Schnittstelle richtig anbinden
eBay API 2026: Welche Sell APIs es gibt, was sich dieses Jahr ändert und wie Bestandsabgleich, Rate Limits und Retouren sauber laufen.
Die Kurzfassung: eBay bietet Händlern zwei Generationen von Schnittstellen. Aktuell sind die REST-basierten Sell APIs: die Inventory API für Bestand und Angebote, die Fulfillment API für Bestellungen und Versand, die Marketing API für Werbeaktionen und die Account API für Konto- und Richtlinien-Einstellungen. Daneben existiert weiterhin die ältere Trading API auf XML-Basis, die einzelne Funktionen abdeckt, die im neuen Stack noch fehlen. 2026 bringt vier relevante Änderungen: Benutzernamen werden in API-Antworten durch unveränderliche User-IDs ersetzt und Finanzdaten bestimmter Nutzer stärker geschützt, ab Anfang Mai gelten standardisierte Zustandsangaben in bestimmten Münz-Kategorien, ab August 2026 können Bekleidungs- und Schuhangebote ohne saubere Größenangaben ausgeblendet oder blockiert werden, und in der Retourenschnittstelle kommt der EU-Rückgabegrund „Right of Withdrawal" hinzu.
Die eBay-Schnittstellen im Überblick
Die Sell APIs sind das moderne Fundament. Sie arbeiten mit REST und JSON, sind nach Aufgabenbereichen getrennt und werden von eBay aktiv weiterentwickelt. Für neue Anbindungen sind sie der Standard.
Die Inventory API ist der Kern für den Handel. Sie trennt sauber zwischen dem Artikel als Lagergut und dem Angebot als Verkaufsobjekt: Zuerst legen Sie einen Bestandsartikel an, dann ein oder mehrere Angebote darauf. Dieses Modell ist der Grund, warum Varianten und Mehrfachlistings damit deutlich sauberer abzubilden sind als früher.
Die Fulfillment API deckt alles nach dem Kauf ab. Sie liest Bestellungen, überträgt Versandbestätigungen und Trackingnummern und stellt Retouren- und Erstattungsvorgänge bereit. Wer Versanddienstleister anbindet, arbeitet hier.
Die Marketing API steuert Werbung und Aktionen, also unter anderem Promoted Listings und Rabattaktionen. Die Account API verwaltet die Einstellungsebene: Versand-, Zahlungs- und Rückgaberichtlinien, Verkäuferprofile und Kontoeinstellungen.
Die Trading API ist die ältere Generation auf XML-Basis. Sie ist nicht tot, aber sie ist auch nicht die Zukunft. Für neue Projekte sollte sie nur dort eingesetzt werden, wo eine benötigte Funktion in den Sell APIs tatsächlich fehlt.
Sell APIs oder Trading API — die praktische Entscheidung
Die häufigste Frage in Projekten lautet, ob man die Trading API noch anfassen sollte. Die ehrliche Antwort: möglichst wenig, aber nicht dogmatisch nie.
Für Bestand, Angebote, Bestellungen, Versand und Richtlinien sind die Sell APIs die richtige Wahl. Sie sind besser dokumentiert, klarer strukturiert und erhalten die Neuerungen zuerst. Alles, was 2026 an Pflichten dazukommt, wird dort umgesetzt.
Es gibt jedoch Randfälle, in denen ältere Funktionen nur über die Trading API erreichbar sind. In solchen Fällen ist ein Mischbetrieb vertretbar — solange klar dokumentiert ist, welche Schnittstelle welchen Datenpunkt besitzt.
Genau das ist der kritische Punkt: Zwei Schnittstellen, die denselben Artikel schreiben, erzeugen Konflikte. Ein Angebot, das über die Inventory API gepflegt und über die Trading API überschrieben wird, verliert reproduzierbar Attribute. Legen Sie deshalb je Datenfeld eine führende Quelle fest.
Für eine Neuanbindung 2026 gilt: Starten Sie vollständig auf den Sell APIs und ergänzen Sie die Trading API nur dann, wenn eine konkrete Funktion nachweislich fehlt. Wer umgekehrt vorgeht, baut eine Migration ein, die später niemand mehr anfassen will.
MarketplAIce 14 Tage kostenlos testen
Was sich 2026 konkret ändert
Die erste Änderung betrifft Identitäten. Benutzernamen werden in API-Antworten durch unveränderliche User-IDs ersetzt, und Finanzdaten bestimmter Nutzer werden stärker geschützt. Wenn Ihre Systeme Käufer über den Benutzernamen zuordnen, bricht diese Logik.
Praktisch heißt das: Prüfen Sie jede Stelle, an der ein eBay-Benutzername als Schlüssel dient — in der Auftragsverwaltung, im Kundenservice-Tool, in Sperrlisten und in Auswertungen. Der Umstieg auf die unveränderliche User-ID ist ohnehin die stabilere Lösung, weil Benutzernamen geändert werden können.
Die zweite Änderung betrifft Münz-Kategorien. Ab Anfang Mai 2026 müssen API-Nutzer beim Anlegen und Aktualisieren von Angeboten in bestimmten Münz-Kategorien standardisierte Zustandsangaben mitliefern. Freitext genügt dort nicht mehr.
Die dritte Änderung ist für den Massenhandel die wichtigste. Angebote in Bekleidung und Schuhen mit fehlenden, unvollständigen oder nicht standardisierten Größenangaben können ab August 2026 ausgeblendet oder blockiert werden. Die Normalisierung dieser Angaben startete im Juni 2026.
Wer hier Bestandslistings mit gewachsener Datenqualität hat, sollte nicht auf eine Fehlermeldung warten. Ein Angebot, das ausgeblendet wird, meldet sich nicht — es verschwindet einfach aus der Suche. Wie standardisierte Attribute grundsätzlich funktionieren, beschreiben wir im Beitrag zu eBay Artikelmerkmalen.
Die vierte Änderung betrifft Retouren. In der Schnittstelle getReturnDetails kommt für berechtigte EU-Retouren ein neuer Rückgabegrund hinzu: „Right of Withdrawal", also der Widerruf. Ihre Integration muss diesen Wert verarbeiten können, ohne in eine Fehlerbehandlung zu laufen.
Fehlertoleranz: Warum neue Enum-Werte Systeme zerlegen
Der neue Rückgabegrund ist ein Lehrbeispiel für ein Problem, das jede Schnittstellenanbindung trifft. Viele Integrationen prüfen Feldwerte gegen eine feste Liste erlaubter Werte und werfen bei Unbekanntem einen Fehler.
Das funktioniert genau so lange, bis der Anbieter einen Wert ergänzt. Dann schlägt der Import fehl, und im schlimmsten Fall bleiben nicht nur die neuen Fälle liegen, sondern der komplette Verarbeitungslauf steht.
Die Lösung ist simpel und sollte überall Standard sein: Unbekannte Enum-Werte dürfen nie zum Abbruch führen. Sie werden durchgereicht, protokolliert und mit einer neutralen Standardbehandlung versehen — im Fall eines unbekannten Retourengrunds etwa als „sonstiger Grund".
Dasselbe Prinzip gilt für neue Felder in Antworten. Eine Integration, die auf zusätzliche Felder mit einem Fehler reagiert, ist ein Wartungsfall auf Abruf. Robuste Systeme ignorieren, was sie nicht kennen, und melden es im Protokoll.
Für Sie als Händler ist das eine konkrete Prüffrage an jeden Anbieter: Was passiert, wenn eBay morgen einen neuen Wert einführt? Wer darauf keine klare Antwort hat, hat sie auch technisch nicht.
Bestandsabgleich und Übermengenverkauf
Der teuerste Fehler in jeder Marktplatz-Anbindung ist der Verkauf von Ware, die nicht mehr da ist. Auf eBay schlägt das direkt auf Stornoquote, Bewertungen und Verkäuferstatus durch.
Die Ursache ist fast immer ein Zeitfenster. Zwischen dem Verkauf auf Kanal A und der Aktualisierung auf Kanal B vergehen Minuten — und in diesen Minuten kauft jemand denselben letzten Artikel ein zweites Mal.
Es gibt drei wirksame Gegenmittel. Erstens: ereignisgesteuerter Abgleich statt fester Intervalle. Ein Verkauf löst sofort eine Aktualisierung aller Kanäle aus, statt auf den nächsten Zyklus zu warten.
Zweitens: Sicherheitsbestand. Sie halten je nach Artikelgeschwindigkeit eine kleine Menge zurück, die nie in die Kanäle gemeldet wird. Das kostet minimal Umsatz und verhindert die teuren Fälle.
Drittens: Priorisierung nach Risiko. Artikel mit einer Restmenge im niedrigen einstelligen Bereich brauchen einen engen Takt, Artikel mit vollem Lager nicht. Diese Logik entlastet gleichzeitig Ihre Rate Limits. Die operativen Grundlagen dazu finden Sie in unserem Leitfaden zur eBay Bestandsverwaltung.
Wichtig ist außerdem die Richtung des Abgleichs. Der Bestand sollte aus einem führenden System heraus in alle Kanäle geschrieben werden, nicht zwischen Kanälen hin- und hergespiegelt. Sonst entstehen Rückkopplungen, bei denen niemand mehr sagen kann, welcher Wert stimmt.
In 7 Schritten zur stabilen eBay-Anbindung
- Führendes System festlegen — Bestimmen Sie, welches System die Wahrheit über Bestand, Preise und Artikeldaten hält. Alle Kanäle werden von dort beschrieben, nicht umgekehrt. Ohne diese Festlegung produziert jede Anbindung früher oder später widersprüchliche Daten.
- OAuth sauber aufsetzen — Richten Sie den Zugang über OAuth ein und vergeben Sie nur die Berechtigungen, die der Anwendungsfall wirklich braucht. Planen Sie die automatische Erneuerung der Token von Anfang an ein. Eine Integration, die manuell nachautorisiert werden muss, fällt genau dann aus, wenn niemand hinschaut.
- Auf Sell APIs starten — Bauen Sie Bestand, Angebote, Bestellungen und Richtlinien vollständig auf Inventory, Fulfillment, Marketing und Account API. Ziehen Sie die Trading API nur für nachweislich fehlende Funktionen hinzu. Dokumentieren Sie jede solche Ausnahme mit Begründung.
- Pflichtattribute bereinigen — Prüfen Sie Ihren Bestand auf die 2026 verschärften Anforderungen, insbesondere Größenangaben in Bekleidung und Schuhen sowie standardisierte Zustandsangaben in den betroffenen Münz-Kategorien. Korrigieren Sie das im führenden System, nicht direkt im Angebot. Sonst überschreibt der nächste Abgleich Ihre Korrektur.
- Fehlertoleranz einbauen — Sorgen Sie dafür, dass unbekannte Enum-Werte und neue Felder protokolliert, aber nie zum Abbruch führen. Testen Sie das aktiv, indem Sie einen erfundenen Wert durch die Verarbeitung schicken. Ein System, das daran scheitert, wird an jeder eBay-Neuerung scheitern.
- Rate Limits einplanen — Verteilen Sie Aufrufe über den Tag, staffeln Sie Abfragen nach Artikelrisiko und behandeln Sie Drosselungen mit steigenden Wartezeiten. Vollabgleiche gehören in Randzeiten, nicht in die Verkaufsspitze. Ein Vollabgleich zur Hauptzeit ist der schnellste Weg in ein leeres Kontingent.
- Überwachung scharf schalten — Richten Sie Alarme für ausbleibende Aktualisierungen, gehäufte Fehlerantworten und Angebote ein, die unerwartet nicht mehr auffindbar sind. Legen Sie zusätzlich einen festen Quartalstermin für Änderungsmeldungen von eBay fest. Die Neuerungen 2026 haben gezeigt, wie kurz die Vorlaufzeiten sein können.
Middleware, ERP oder Eigenentwicklung
Für die meisten Händler stellt sich die Frage nicht als Grundsatzentscheidung, sondern als Kostenrechnung. Eine Eigenentwicklung ist attraktiv, wenn Sie sehr spezielle Prozesse haben und dauerhaft Entwicklerkapazität halten.
Der Aufwand liegt dabei nicht in der ersten Version. Er liegt in den Jahren danach: neue Pflichtfelder, geänderte Enum-Werte, angepasste Rate Limits, wechselnde Authentifizierungsvorgaben. Wer diese Arbeit nicht dauerhaft einplant, betreibt eine Integration, die langsam verrottet.
Middleware und ERP-Anbindungen nehmen Ihnen genau diese Pflege ab. Der Preis dafür sind Standardprozesse, in die Sie sich einfügen müssen. Für den Großteil der Händler ist das der bessere Tausch.
Die dritte Variante ist die häufigste: ein ERP oder eine Middleware für die operative Abwicklung, ergänzt um eine spezialisierte Lösung wie MarketplAIce für Steuerung und Optimierung. Abwicklung und Entscheidung sind unterschiedliche Aufgaben und brauchen selten dasselbe System.
Prüfen Sie bei jedem Anbieter drei Dinge: wie schnell er auf angekündigte eBay-Änderungen reagiert, wie er mit Drosselungen umgeht, und ob er neben eBay auch Ihre anderen Kanäle abdeckt. Getrennte Systeme je Kanal erzeugen getrennte Wahrheiten.
Steuerung über Kanalgrenzen hinweg
Eine saubere Anbindung liefert Daten. Was daraus wird, ist eine zweite Frage — und hier trennen sich Abwicklung und Optimierung.
MarketplAIce setzt auf der Datenebene auf und arbeitet kanalübergreifend. Bestände, Preise, Wettbewerbssituation und Werbeleistung werden nicht je Marktplatz isoliert betrachtet, sondern zusammen. Das ist entscheidend, wenn derselbe Artikel auf eBay und auf anderen Marktplätzen liegt.
Der Unterschied zu klassischen Tools ist der Zeitpunkt der Entscheidung. Reaktive Systeme melden, dass eine Kennzahl gekippt ist. MarketplAIce rechnet über 15 Dimensionen fünf Tage voraus, wie sich Nachfrage, Wettbewerb und Marge je Artikel entwickeln, und steuert Preise und Gebote entlang dieser Prognose.
Für die eBay-Anbindung sind dabei drei Punkte praktisch relevant. Bestandsprognosen verhindern, dass Werbebudget in Artikel läuft, die in wenigen Tagen ausverkauft sind. Das Repricing berücksichtigt Kanalgebühren statt nur Wettbewerbspreise. Und Datenlücken durch Drosselungen werden erkannt, statt stillschweigend zu veralteten Zahlen zu führen.
Sie autorisieren den Zugang einmal über den regulären Weg, ohne Zugangsdaten weiterzugeben. Der Einstieg beginnt im Essential-Tarif, die vollständige Übersicht steht unter Preise und Tarife.
FAQ
Welche eBay-API brauche ich für Bestand und Angebote?
Die Inventory API aus den Sell APIs. Sie trennt zwischen dem Bestandsartikel und dem Angebot darauf, was Varianten und Mehrfachlistings deutlich sauberer abbildet. Für Bestellungen und Versand kommt die Fulfillment API dazu, für Richtlinien die Account API und für Werbeaktionen die Marketing API.
Kann ich die Trading API noch verwenden?
Ja, sie existiert weiterhin auf XML-Basis. Für neue Anbindungen sollte sie aber nur dort eingesetzt werden, wo eine benötigte Funktion in den Sell APIs tatsächlich fehlt. Wichtig ist, je Datenfeld eine führende Schnittstelle festzulegen, damit sich beide nicht gegenseitig überschreiben.
Was ändert sich 2026 bei Benutzernamen in der API?
Benutzernamen werden in API-Antworten durch unveränderliche User-IDs ersetzt, und Finanzdaten bestimmter Nutzer werden stärker geschützt. Wenn Ihre Systeme Käufer über den Benutzernamen zuordnen, müssen Sie auf die User-ID umstellen. Das ist ohnehin die stabilere Lösung, weil Benutzernamen geändert werden können.
Was gilt ab August 2026 für Bekleidung und Schuhe?
Angebote in Bekleidung und Schuhen mit fehlenden, unvollständigen oder nicht standardisierten Größenangaben können ab August 2026 ausgeblendet oder blockiert werden. Die Normalisierung dieser Angaben startete im Juni 2026. Prüfen Sie Ihren Bestand aktiv — ausgeblendete Angebote erzeugen keine Fehlermeldung, sie verschwinden aus der Suche.
Was ist beim neuen Rückgabegrund „Right of Withdrawal" zu beachten?
In der Schnittstelle getReturnDetails kommt für berechtigte EU-Retouren der Rückgabegrund „Right of Withdrawal", also der Widerruf, hinzu. Ihre Integration muss diesen Wert verarbeiten können. Grundsätzlich sollten unbekannte Enum-Werte nie zu einem Abbruch führen, sondern protokolliert und neutral behandelt werden.
Wie vermeide ich Übermengenverkauf über mehrere Kanäle?
Mit drei Maßnahmen: ereignisgesteuerter Abgleich statt fester Intervalle, ein kleiner Sicherheitsbestand bei schnelldrehenden Artikeln und eine Priorisierung, die Artikel mit niedriger Restmenge häufiger aktualisiert. Entscheidend ist außerdem, dass der Bestand aus einem führenden System heraus in alle Kanäle geschrieben wird.
Was passiert bei Überschreitung der Rate Limits?
Die Aufrufe werden gedrosselt und liefern statt Daten eine Fehlerantwort zurück. Eine gute Integration wartet dann mit steigenden Abständen und wiederholt den Aufruf, statt sofort erneut anzufragen. Vollabgleiche gehören in Randzeiten, damit das Kontingent in der Verkaufsspitze verfügbar bleibt.
Über den Autor
Jorginho Engelmeyer ist Founder von MarketplAIce und arbeitet seit über 8 Jahren im Marktplatz- und Amazon-Advertising. Er hat den Aufbau kanalübergreifender Anbindungen für Händler und Agenturen begleitet und kennt beide Seiten: die operative Abwicklung über ERP und Middleware und die Steuerungsebene, auf der aus Rohdaten Preis- und Gebotsentscheidungen werden. Sein Fokus liegt darauf, diese Entscheidungen prädiktiv statt rückblickend zu treffen. Mehr zur Expertise