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.
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.
| Surface | Roles |
|---|---|
| Compliance | Vehicle 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.
| Stage | Call | What exists afterwards |
|---|---|---|
| Open the case | POST /compliance/cases | facilityId, jurisdiction and legalProfile bind the case to site and law |
| Record the intake | POST /compliance/cases/{id}/intake | transferor and custody fix who handed over and in whose custody the vehicle now is |
| Determine the status | POST /compliance/cases/{id}/status-determinations | basisCode and outcome — the classification carries its legal basis with it |
| Identify the owner | POST /compliance/cases/{id}/owner-identification | status and attempts evidence the effort, not only the result |
Why each stage is needed
- Open the case.
POST /compliance/casestakesfacilityId,jurisdiction,legalProfileand 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. - Record the intake.
POST /compliance/cases/{id}/intakecarriestransferOccurredAt,intakeType,transferorandcustody. The passing of custody is the real core, which is why it is documented rather than estimated. - Determine the status.
POST /compliance/cases/{id}/status-determinationstakesbasisCode,outcomeandeffectiveAt. The classification carries its legal basis with it — that is the difference between a determination that survives an audit and an assertion. - Document the owner identification.
POST /compliance/cases/{id}/owner-identificationcarriesstatusandattempts. 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.
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.
Sources and legal references
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.
