Dossier véhicule depuis le certificat : réception, état, annonce

Un véhicule arrive en reprise, en retour de leasing ou à l’achat. Avant sa mise en ligne, il est généralement saisi trois fois : pour l’ERP, pour l’évaluation, pour l’annonce. Chaque saisie est une occasion d’inverser un chiffre du numéro de châssis, et chacune coûte du temps pendant lequel le véhicule occupe de la place au lieu de rapporter.

Le Hub inverse l’ordre : la photo du certificat ouvre le dossier, et la récupération des données techniques comme l’annonce dépendent du tapiId, s’il est renvoyé. Le rapport d’état via POST /vision/condition-report ne prend aucun tapiId ; il est établi à partir des seules photos soumises.

Ce que ce cas suppose

• Une photo lisible du certificat. L’appel prend une adresse d’image accessible, non un fichier téléversé. Une vignette de quelques centaines de pixels ne contient aucun numéro de châssis lisible — chargez la plus grande version disponible.
• Le droit sur le document. Un certificat contient des données personnelles. En l’envoyant, vous confirmez être habilité à le transmettre et à le faire traiter automatiquement.
• Des photos du véhicule si un rapport d’état est souhaité. Sans images, pas d’état justifié ; rien n’est estimé.
• Un endroit pour stocker le tapiId. La récupération des données techniques et l’annonce l’exigent comme paramètre de chemin ; sans lui, ces deux étapes n’ont pas lieu.
• Le droit d’interroger le véhicule. Par l’appel, vous confirmez être détenteur, propriétaire ou mandaté de façon prouvée, ou autrement habilité en droit, et utiliser le numéro de châssis exclusivement pour la finalité licite indiquée.

Le déroulement

Le tableau indique pour chaque étape l’appel compétent et ce qui existe ensuite. La justification de l’étape figure en dessous.

Pourquoi chaque étape est nécessaire

1. Ouvrir le dossier. POST /vehicles/intake lit le certificat indiqué par fileUrl, prend en option des photos du véhicule dans photoUrls et crée le dossier véhicule. Outre l’extrait de texte, le résultat contient un identifiant, le tapiId, qui peut valoir null. Ne pas le stocker, c’est avoir fait la réception et en avoir perdu le bénéfice.
2. Récupérer les données techniques. GET /vehicles/{tapiId} renvoie modèle, motorisation et détails techniques pour le dossier. Cette étape explique pourquoi le certificat suffit : la profondeur technique vient des données de référence, non du document.
3. Documenter l’état. POST /vision/condition-report établit un rapport d’état à partir des photos soumises. Il décrit ce que montrent les images. Une rayure non photographiée n’apparaît pas au rapport — et ne doit pas y apparaître.
4. Produire l’annonce. POST /vehicles/{tapiId}/listing rédige le texte prêt pour les portails. Issu du dossier, il ne cite aucun équipement non justifié. C’est la différence entre une annonce qui vend et une annonce contestée ensuite.

curl -X POST \
  -H 'X-Api-Key: <API_KEY>' \
  -H 'Content-Type: application/json' \
  -H 'Idempotency-Key: hereinnahme-2026-0412' \
  -d '{"fileUrl":"https://example.com/fahrzeugschein.jpg","photoUrls":["https://example.com/front.jpg","https://example.com/heck.jpg"],"includeOwner":false}' \
  'https://api.tapinomahub.com/vehicles/intake'

Ce que l’on obtient

Il reste un dossier véhicule où chaque donnée renvoie à un document, à des données de référence ou à une photo. Le texte d’annonce est produit à partir des données véhicule documentées pour le tapiId ; le rapport d’état reste lié aux photos soumises.

Où cela figure dans la documentation

Les listes de champs contractuelles, les codes d’erreur et les réponses d’exemple se trouvent dans le contrat OpenAPI de cette surface, à l’adresse docs.tapinomahub.com (tapinoma-hub). Tous les cas d’usage classés par surface et par rôle : aperçu des cas d’usage.