From the dismantling bay to the sale — release first, price second

A headlight is removed at the dismantling bay. It looks flawless, and a colleague wants to list it straight away. But nobody has yet decided whether it may be sold as a reusable part — and that decision is precisely what is asked first in a complaint or an audit.

The chain spans three surfaces and fixes the order: the reuse assessment in the Compliance surface comes before the price and marketplace query in the Hub, and only after that does Commerce create an item with an offer. A process that keeps this order creates no offer without a documented release.

What this case requires

• A competent person for the assessment. The reuse assessment is carried out by a signed-in person in the responsible role; an API key is not enough.
• A legible label on the removed part. The OE number comes from the part, not from memory.
• A connected channel for the sale. The offer references a connection and a pricing policy.
• Your own item number. The catalogue item carries your merchantSku, the offer the concrete stocked piece.

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. Assess reuse. POST /compliance/parts/{id}/assessments takes result, reuseSafetyStatus, condition, defects, tests, materials and evidence. Reuse safety is a statement of its own, separate from condition — and a signed-in person carries out the assessment.
2. Read the number. POST /scanner/label/extract-partnumbers returns the partNumbers from the label of the removed part. The number comes from the part itself, not from the donor vehicle’s parts list.
3. Evaluate the price. GET /parts/oe/{oeNumber}/price with condition used returns an indicative valuation with min, max and average. It is not a price guarantee.
4. Build the marketplace data. GET /parts/oe/{oeNumber}/seo returns content.ebayTitle, categoryId and itemSpecifics. Part data become selling copy without anyone searching for a category.
5. Create the item. PUT /commerce/v1/catalog/items/{catalogItemId} stores the canonical version with merchantSku, condition and identifiers. The item describes, the stocked piece exists — the two stay separate.
6. Prepare the offer. PUT /commerce/v1/offers/{offerId} ties together stockItemId, connectionId, price and pricingPolicyId. publicationState takes draft, ready, paused and withdrawn; the contract does not describe what these states do. In the example the offer is submitted as draft.

curl -X PUT \
  -H 'X-Api-Key: <API_KEY>' \
  -H 'Content-Type: application/json' \
  -H 'Idempotency-Key: angebot-scheinwerfer-88213' \
  -d '{"stockItemId":"<stockItemId>","connectionId":"<connectionId>","price":{"amountMinor":12900,"currency":"EUR"},"pricingPolicyId":"<pricingPolicyId>","publicationState":"draft","revision":"<revision>"}' \
  'https://commerce-preview.invalid/commerce/v1/offers/<offerId>'

What you end up with

What remains is an offer backed by a documented reuse decision by a named person, a number read off the part, a traceable price basis and marketplace copy. The headlight is sold not because it looked good, but because it was released.

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-compliance, tapinoma-hub, tapinoma-commerce). All use cases arranged by surface and role: overview of the use cases.