Showing the damage on a body part before it is removed

A recycler wants to sell a driver’s door before removing it: only what is sold gets removed. But the photos from the vehicle show the door at an angle, with neighbouring parts and background. A buyer wants to see the door in a standard view — with the damage it actually has.

The damage transfer carries only visible findings from the mounted part onto provided standard views of the same component. Anything that cannot be assigned reliably stays out of the image and is listed in notTransferred; hidden rear sides and unphotographed surfaces are not filled in. The result is an edited view, not a photo of the individual part — and must stay recognisable as such.

What this case requires

• One to five photos of the mounted part. A mask can optionally be supplied per photo via partMaskUrl.
• Standard views of the same component. Up to six target views; each names its view. Without a standard view of your own there is no target.
• The part’s OE number. It carries the marketplace data; the damage transfer itself does not need it.
• A label in the listing. The target views are edited representations; per asset provenance.requiredLabel names the label, and provenance.disclosureEmbedded is true.

The sequence

The table names the responsible call per stage and what exists afterwards. The reasoning for why a stage cannot be skipped follows below it.

Why each stage is needed

1. Describe the damage. POST /vision/damage/describe takes up to five imageUrls of the same damage and returns a report; textQuality chooses between notes, prose and expert. The text describes what is visible and is the basis for the item description.
2. Transfer the damage. POST /vision/part/damage-transfer takes sources with the mounted part and targets with the standard views, each with view and optionally a mask. Back come assets per edited target view with provenance, findings with type, location, confidence and transferredToViews, and notTransferred. If the output cannot be verified reliably, the call answers with 422 and damage_not_transferable or image_edit_unverified.
3. Grade the condition. POST /vision/part/quality returns grade, reworkEffort and refinishEffort with criteria and observations — or gradable false when the images cannot carry it. The grade belongs in the listing, the effort in the buyer’s calculation.
4. Build the marketplace data. GET /parts/oe/{oeNumber}/seo returns content.ebayTitle, categoryId, itemSpecifics and keywords for the chosen marketplace. The title describes the part; the damage belongs in description and condition, not in an embellished headline.

curl -X POST \
  -H 'X-Api-Key: <API_KEY>' \
  -H 'Content-Type: application/json' \
  -H 'Idempotency-Key: tuer-links-schaden-0917' \
  -d '{"sources":[{"imageUrl":"https://example.com/tuer-montiert.jpg","view":"left"}],"targets":[{"imageUrl":"https://example.com/tuer-standard-links.jpg","view":"left"}],"partType":"Fahrertür links","quality":"standard","output":{"size":"1536x1024","format":"jpeg"}}' \
  'https://api.tapinomahub.com/vision/part/damage-transfer'

What you end up with

What remains is a listing for a part still on the vehicle, with edited standard views onto which visible findings were transferred, a condition grade and a description. It is removed once sold.

Where to find this in the documentation

The binding field lists, error codes and sample responses live in this surface’s OpenAPI contract at docs.tapinomahub.com (tapinoma-hub). All use cases arranged by surface and role: overview of the use cases.