Teilehersteller, Zulieferer und Datenlieferanten: OE-Referenzen prüfen und Artikeldaten anreichern

Wo im Prozess Daten fehlen

Ein Artikel eines Zulieferers trägt eine eigene Nummer und eine Liste der OE-Nummern, die er ersetzt. Diese Liste ist der Anker, über den Handel und Werkstatt den Artikel finden — und der Teil des Datensatzes, der am häufigsten in Handarbeit entsteht, siehe OE-Nummer. Die typischen Stellen:

• Beim Anlegen der Referenzliste. OE-Nummern kommen aus Konstruktionsunterlagen, Händlerrechnungen und Wettbewerberkatalogen — mit Leerzeichen, mit Bindestrichen, ohne Indexbuchstaben. Ob 5Q0 919 275 C und 5Q0919275C dieselbe Nummer sind, entscheidet ein Mitarbeiter beim Lesen.
• Bei der Klassifikation. Artikelart und VDI-4081-Position werden je Artikel aus einem Aufklappmenü gewählt. Bei Verschleißteilen ist das schnell, bei Elektronik und Karosserie selten einheitlich.
• Bei der Übersetzung. Bezeichnungen werden je Zielsprache von Hand übersetzt oder aus einem alten Katalog übernommen; Marktplatztexte je Land noch einmal.
• Bei der Preisorientierung. Wo ein Artikel im Markt steht, wird aus einzelnen Wettbewerberpreisen abgeleitet, ohne Datum und ohne Quelle.
• Nach der Lieferung. Ob eine OE-Nummer in der eigenen Liste inzwischen von einem Rückruf betroffen ist, prüft niemand — die Register sind nicht an die Stammdaten angeschlossen.

Was die Schnittstelle liefert

Ein Ablauf von Anfang bis Ende

1. Klassifikation einmal vorbereiten. GET /vdi liefert den VDI-4081-Katalog mit Hauptgruppen und Positionen, dazu Stand und Prüfwert. Damit bilden Sie Ihre Warengruppensystematik einmal auf VDI 4081 ab; OE-Zuordnungen enthält der Katalog nicht, die kommen je Nummer aus dem Abgleich.
2. Referenzliste bereinigen. Jede OE-Nummer der Liste geht mit oeNumber und, wo bekannt, manufacturer durch GET /parts/oe/normalize. Bei matched übernehmen Sie die normalisierte Schreibweise und die dokumentierten Ersatznummern. unresolved, ambiguous und invalid bleiben als Eingabe stehen und bekommen eine Aufgabe — kein Fall wird durch Raten geschlossen.
3. Artikel klassifizieren. Für jede bestätigte Nummer liefert GET /parts/oe/{oeNumber} genau eine tapiGenArt und, wo eine bestätigte Zuordnung vorliegt, die VDI-4081-Position; ist die VDI-4081-Zuordnung leer, bleibt die Warengruppe offen. Dazu kommen Ersetzungskette, Referenzfamilie und Fitment — siehe GenArt-Nummer. Kommt 404, gab es keinen bestätigten Basistreffer: Der Artikel bleibt angelegt, die Klassifikation offen.
4. Eigene Referenzen gegen den Markt halten. GET /parts/oe/{oeNumber}/aftermarket-references zeigt, welche Aftermarket-Referenzen zu einer OE-Nummer dokumentiert sind — so sieht ein Datenlieferant, wo die eigene Liste vom Markt abweicht. Eine Referenz ist keine Garantie für Passung; eine leere Liste ist ein Befund, kein Fehler — siehe OE, OEM, OES und IAM.
5. Bezeichnungen und Marktplatztexte. Die Teilebezeichnung geht einzeln durch GET /translation/translations — genau eine je Aufruf, keine Titel oder Listen. GET /parts/oe/{oeNumber}/seo liefert je Sprache und Marktplatz Produkt-, Inhalts- und Merkmalsfelder; der Text wird vor Veröffentlichung geprüft.
6. Preis einordnen. GET /parts/oe/{oeNumber}/price gibt eine indikative Preisbewertung aus Vergleichs- und Marktreferenzen zurück. Sie gehört als Marktreferenz mit Datum in den Datensatz, nicht als Listenpreis — und sie ist keine Preisgarantie.
7. Rückrufe im Nachtlauf. Ein Job schickt die Referenzliste in Paketen von bis zu 100 Positionen an POST /recalls/parts, mit vehicle.make, vehicle.model und Bauzeitraum, wo bekannt. Je Position kommen Status, Maßnahmen und Konfidenz zurück; betroffene Artikel bekommen einen Hinweis für die Handelspartner.

curl \
  -H 'X-Api-Key: <API_KEY>' \
  'https://api.tapinomahub.com/parts/oe/normalize?oeNumber=5Q0919275C&manufacturer=VOLKSWAGEN'

Der Einbau

1. Schlüssel serverseitig hinterlegen. Der Schlüssel im Header X-Api-Key gehört in die Konfiguration Ihres Backends oder Batch-Systems — nie in den Browser, nie in ein Import-Skript, das mit dem Datenpaket weitergegeben wird. Der Weg von Vertrag bis Go-live steht in der Dokumentation.
2. Mit einem Endpunkt beginnen. Für Stammdaten ist das GET /parts/oe/normalize beim Import der Referenzliste: ein Aufruf je Nummer, und jede Zeile hat danach einen status, den man zählen kann.
3. Feldzuordnung festlegen. Die normalisierte Nummer und die Ersatznummern in das Referenzfeld, tapiGenArt auf Ihre Artikelart, die VDI-4081-Zuordnung auf Ihre Warengruppe, part.manufacturer und part.name in die Stammfelder — und jedes Feld, das null liefert, bleibt leer.
4. Fehlerfall und Leerbefund trennen. unresolved, ambiguous und invalid bei der Normalisierung, 404 beim OE-Abgleich und eine leere Referenzliste sind Leerbefunde: Datensatz behalten, Feld leer lassen, Aufgabe erzeugen. Nur ein technischer Fehler wird wiederholt.
5. Antworten mit 202 abholen. Lang laufende Vorgänge antworten mit 202, Location, Retry-After und einer Job-ID; der Status kommt aus dem zugehörigen .../jobs/{jobId}-Endpunkt im Abstand von Retry-After — etwa GET /vin/cart-check/jobs/{jobId}, wenn POST /vin/cart-check bis zu 30 OE-Positionen gegen ein Fahrzeug prüft, oder GET /vision/part/generation-jobs/{jobId} für Produktbild-Jobs zu Neuteilen aus POST /vision/part/generate.
6. Ausrollen und beobachten. Erst eine Warengruppe, dann der Bestand. GET /client/usage zeigt, welche Aufrufe wie oft laufen; der Header X-Tapinoma-Usage-Warning meldet sich, bevor das Guthaben ausgeht.

Worauf zu achten ist

• Idempotency-Key setzen. Ein Nachtlauf, der nach einem Neustart erneut startet, schickt dieselben Pakete an POST /recalls/parts. Mit dem Header Idempotency-Key wird die Wiederholung erkannt und im Antwortheader X-Tapinoma-Idempotent-Replay ausgewiesen. Ausnahme: Aufrufe, die einen Schlüssel einmalig ausgeben — nach einem Timeout Bestand abgleichen statt erneut anlegen.
• Leere Felder nicht füllen. unresolved heißt nicht „wahrscheinlich diese Nummer“, und ein null in part.listPrice ist eine Aussage. Ein Datensatz, der Lücken plausibel schließt, trägt die Falschaussage in jeden Katalog, der Ihre Daten übernimmt.
• tapiId speichern. Hat ein Vorgang ein Fahrzeug über einen VIN-Ablauf abgeglichen, behalten Sie die tapiId; GET /vehicles/{tapiId} liefert die technischen Daten als Bestandteil dieses bezahlten Ablaufs, ohne VIN und Ausstattung.
• Ergebnisse speichern, nicht je Export neu abfragen. Was GET /parts/oe/{oeNumber} liefert, gehört an die Nummer in Ihrer Datenbank; jede Anfrage wird aus dem Guthaben berechnet.
• Schlüssel nie im Browser. Auch ein Prüfwerkzeug für das Katalogteam läuft über Ihr Backend; Rate-Limits je Unter-Nutzer begrenzen einen Import, der versehentlich den ganzen Bestand neu prüft.
• SEO-Inhalte nicht als Passung ausliefern. Die SEO-Anreicherung erstellt Veröffentlichungstexte und Artikelmerkmale. Eine Passungsaussage muss aus dem dafür vorgesehenen Teile- oder VIN-Abgleich stammen.
• Ergebnis vor der Lieferung prüfen. Übersetzung, SEO-Anreicherung und Preisbewertung sind zur Prüfung gedacht, nicht zur ungesehenen Weitergabe. Die Verwendung der Ergebnisse liegt beim Kunden.

Was die Schnittstelle nicht tut

Die Schnittstelle liefert Abgleiche und Analysen, keinen Datenbestand: Mit dem Ergebnis erwerben Sie keine Rechte an den zugrunde liegenden Datenbeständen und keinen Katalog, den Sie weiterlizenzieren könnten. Geschuldet ist die Abfrage; Prüfung und Verwendung der Ergebnisse liegen bei Ihnen. GET /vdi liefert den Klassifikationskatalog ohne OE-Zuordnungen, die Preisbewertung ist indikativ und keine Preisgarantie, eine Aftermarket-Referenz ist keine Passungszusage. Fahrzeugdaten von Provider 1 werden von Drittsystemen nicht direkt abgerufen — dafür gibt es den Browser-Redirect über POST /vin/redirect-sessions, dessen Session nach zehn Minuten verfällt und weder Fahrzeug- noch Zugangsdaten enthält. Die Bild-Endpunkte liefern Sichtprüfungen, kein Gutachten; ein Kennzeichen auf einer Aufnahme führt zu keiner Halterabfrage. Und wo der Bestand nichts hergibt, bleibt das Feld leer.