Passt das Teil zum Fahrzeug? Den Warenkorb gegen die VIN prüfen

Ein Kunde legt drei Teile in den Warenkorb und tippt seine Fahrgestellnummer ein. Zwei Teile passen, eines passt zu einer anderen Motorisierung derselben Baureihe. Fällt das nicht an der Kasse auf, fällt es beim Einbau auf — und dann kostet es Versand, Rücksendung, Gutschrift und einen verärgerten Kunden.

Der Warenkorbcheck nimmt den ganzen Korb in einem Aufruf an. Liegt das Ergebnis sofort vor, kommt es direkt mit 200 zurück. Kann eine Fahrzeugprüfung nicht unmittelbar abgeschlossen werden, antwortet die API mit 202 und einer jobId, und das Ergebnis wird über den Status-Endpunkt abgeholt.

Was dieser Fall voraussetzt

• Eine Fahrgestellnummer vom Kunden. Ohne sie gibt es keinen Bezug, gegen den geprüft werden kann.
• Die Positionen des Warenkorbs als Nummern. Freitext im Warenkorb ist kein Prüfgegenstand; deshalb steht die Normalisierung am Anfang.
• Eine Stelle in der Kasse, die auf das Ergebnis warten kann. Antwortet die API mit 202, liegt das Ergebnis erst über den Status-Endpunkt vor — die Oberfläche muss das abbilden können.
• Eine Festlegung, was bei `fits=false` und `complete=false` passiert. Bestellung zulassen mit Hinweis oder blockieren: Das ist eine kaufmännische Entscheidung.
• Die Berechtigung zur Fahrzeugabfrage. Mit dem Aufruf bestätigen Sie, Halter, Eigentümer oder nachweislich bevollmächtigt beziehungsweise anderweitig rechtlich berechtigt zu sein und die Fahrgestellnummer ausschließlich für den angegebenen zulässigen Zweck zu verwenden.

Der Ablauf

Die Tabelle nennt je Stufe den zuständigen Aufruf und das, was danach vorliegt. Die Begründung, warum die Stufe nicht übersprungen werden kann, steht darunter.

Warum jede Stufe nötig ist

1. Die Nummern normalisieren. GET /parts/oe/normalize macht aus einer abgetippten Schreibweise einen lookupKey. Ohne diesen Schritt prüft man Bindestriche und Leerzeichen mit, und der Korb fällt aus Formgründen durch.
2. Den Korb prüfen. POST /vin/cart-check nimmt eine bis 30 Positionen auf einmal als oeNumbers, dazu vin und das Pflichtfeld mode mit type oder vehicle. Ein Aufruf für den ganzen Korb ersetzt die Abfrage je Position; die Antwort behält Reihenfolge und Duplikate der Eingabe bei.
3. Das Ergebnis abholen. Nach einer 202-Antwort liefert GET /vin/cart-check/jobs/{jobId} den Status; bei succeeded enthält result je Position oe und fits sowie für den Korb complete. Ist complete=false, ist ein negatives Einzelergebnis kein abschließender Ausschluss.

curl -X POST \
  -H 'X-Api-Key: <API_KEY>' \
  -H 'Content-Type: application/json' \
  -H 'Idempotency-Key: korb-88213' \
  -d '{"vin":"<VIN>","country":"de","mode":"vehicle","oeNumbers":["8K0959455K","1K0121207AK"]}' \
  'https://api.tapinomahub.com/vin/cart-check'

Was am Ende vorliegt

Am Ende steht eine Kasse, die den Kunden warnt, bevor er bezahlt. Das senkt die Rücksendequote, und es senkt sie am richtigen Ende: nicht durch strengere Rückgabebedingungen, sondern durch weniger falsche Bestellungen.

Wo das in der Dokumentation steht

Die verbindlichen Feldlisten, Fehlercodes und Beispielantworten stehen im OpenAPI-Vertrag dieser Fläche unter docs.tapinomahub.com (tapinoma-hub). Alle Anwendungsfälle nach Fläche und Rolle geordnet: Übersicht der Anwendungsfälle.