Taking in a vehicle and determining its legal statusAll articles

Taking in a vehicle and determining its legal status

Whether a vehicle is end-of-life or used decides everything that follows. This case shows how the classification is recorded together with its legal basis.

Published: 2026-09-12Reading time: 5 mintapinomahub API & workflows
API & processesVINAPIRecyclingDocuments & PDF

A vehicle is put on the yard. Who brought it is noted, nothing more. Later a certificate of destruction is to be issued, and then exactly what nobody documented is missing: when custody passed, on what basis the vehicle counts as end-of-life and whether the owner was asked at all.

Taking in a vehicle and determining its legal statusInput: a vehicle is handed over — whether end-of-life or used is still open 1. Open the case (POST /compliance/cases): facilityId, jurisdiction and legalProfile bind the case to site and law 2. Record the intake (POST /compliance/cases/{id}/intake): transferor and custody fix who handed over and in whose custody the vehicle now is 3. Determine the status (POST /compliance/cases/{id}/status-determinations): basisCode and outcome — the classification carries its legal basis with it 4. Identify the owner (POST /compliance/cases/{id}/owner-identification): status and attempts evidence the effort, not only the result Output: a case with an unbroken event chain that knows what is still missing blockers name what is missing instead of letting the case pass silently; hard separates obstacle from hint.Taking in a vehicle and determining its legal statusInput: a vehicle is handed over — whether end-of-life or used is still open01Open the casePOST /compliance/casesfacilityId, jurisdiction and legalProfile bind the case to site and law02Record the intakePOST /compliance/cases/{id}/intaketransferor and custody fix who handed over and in whose custody the vehicle now is03Determine the statusPOST /compliance/cases/{id}/status-determinationsbasisCode and outcome — the classification carries its legal basis with it04Identify the ownerPOST /compliance/cases/{id}/owner-identificationstatus and attempts evidence the effort, not only the resultOutput: a case with an unbroken event chain that knows what is still missingblockers name what is missing instead of letting the case pass silently; hard separates obstacle from hint.
Four calls from opening the case to identifying the owner. Every stage carries its legal basis with it.

The Compliance surface is therefore built as an event chain and not as a form: every successful command produces an event with hash and previousHash, and its response names blockers — that is, what is still missing. A case does not pass silently just because nobody looked.

SurfaceRoles
ComplianceVehicle recyclers, Dealership, Vehicle trading

What this case requires

  • A recognised facility as sender. The legal issuer is the recognised dismantling facility or authorised treatment facility — not the platform.
  • An organisation identifier in the call. The surface expects it as a header; it binds every event to the responsible organisation.
  • An idempotency key. A repeated call must not write a second event into the chain.
  • The willingness to read blockers. A response with hard blockers is a request for action, not an error message to dismiss.

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.

The call chain of this use case
StageCallWhat exists afterwards
Open the casePOST /compliance/casesfacilityId, jurisdiction and legalProfile bind the case to site and law
Record the intakePOST /compliance/cases/{id}/intaketransferor and custody fix who handed over and in whose custody the vehicle now is
Determine the statusPOST /compliance/cases/{id}/status-determinationsbasisCode and outcome — the classification carries its legal basis with it
Identify the ownerPOST /compliance/cases/{id}/owner-identificationstatus and attempts evidence the effort, not only the result

Why each stage is needed

  1. Open the case. POST /compliance/cases takes facilityId, jurisdiction, legalProfile and the vehicle. The legal frame is therefore set at the start, not adjusted at the end — an event chain that swaps its rule set midway would not be auditable.
  2. Record the intake. POST /compliance/cases/{id}/intake carries transferOccurredAt, intakeType, transferor and custody. The passing of custody is the real core, which is why it is documented rather than estimated.
  3. Determine the status. POST /compliance/cases/{id}/status-determinations takes basisCode, outcome and effectiveAt. The classification carries its legal basis with it — that is the difference between a determination that survives an audit and an assertion.
  4. Document the owner identification. POST /compliance/cases/{id}/owner-identification carries status and attempts. What is evidenced is the effort, not only the result: for an ownerless vehicle that is exactly the decisive question, and there is a dedicated call for routing it to a treatment facility.
Open a recycling case
curl -X POST \
  -H 'X-Api-Key: <API_KEY>' \
  -H 'X-Compliance-Organisation-Id: <ORGANISATION>' \
  -H 'Idempotency-Key: fall-2026-09-12-017' \
  -H 'Content-Type: application/json' \
  -d '{"facilityId":"<facilityId>","jurisdiction":"DE","legalProfile":"DE_FZV_ANNEX_9_CURRENT","vehicle":{"vin":"<VIN>"}}' \
  'https://api.tapinomahub.com/compliance/cases'

What you end up with

What remains is a case with an unbroken event chain whose classification is reasoned and which itself says what is missing next. Treatment, certificate and authority notification build on that, without anything having to be narrated after the fact.

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

Frequently asked

Who is the legal issuer?

The recognised facility or authorised treatment facility. Every successful command response reports the platform’s role in platformRole; the server creates the snapshot of the issuing organisation in issuerSnapshot only when the certificate of destruction is issued.

What does a hard blocker mean?

That a prerequisite is missing which must not be skipped. In a successful response every blocker carries code, message and hard, where applicable a requirementId; if a hard gate blocks the action itself, the server responds with status 422 and an error response.

Do I have to check the event chain myself?

Not continuously. For a case or a period there is an audit export that emits events with their hashes — a gap shows up there.