When a vehicle intake is not the normal case

A vehicle without papers stands on the premises, left there overnight. The same day an employee takes in a vehicle although the site is not authorised for it. Both happen, and in an audit both are judged not by whether they happened but by how they were handled.

The Compliance surface gives each of these special cases its own command with its own evidence. Which branch applies depends on the individual case; the event chain records that and how a decision was made — with time, organisation and acting person.

What this case requires

• A created case. All commands except the receipt delivery refer to a case; each of the five commands requires the current ETag version in If-Match.
• The organisation in the call. X-Compliance-Organisation-Id binds every event to the responsible organisation.
• A signed-in person for the disposal decision. The owner’s decision is only recorded in a human session; an API key is not enough.
• A target facility for ownerless vehicles. The routing names the receiving treatment facility explicitly.

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. Document the impermissible intake. POST /compliance/cases/{id}/unauthorized-receipt-incidents takes receivedAt, location, reason and at least one entry in safeguards. What is recorded is not only that something went wrong, but how the vehicle is secured until clarification.
2. Identify the owner. POST /compliance/cases/{id}/owner-identification takes status with identified, pending or not_identifiable and the attempts made. What is evidenced is the effort, not only the result — with not_identifiable in particular, that effort is the actual evidence.
3. Record the disposal decision. POST /compliance/cases/{id}/owner-disposition-decisions takes ownerPartyId, decision, effectiveAt and an attestationId. Only a signed-in person can record this; an API key alone is not enough.
4. Route the ownerless vehicle. POST /compliance/cases/{id}/ownerless-routing names the target facility in targetAtfFacilityId and the planned transfer in plannedTransferAt. The routing is planned and named, not a pick-up on request.
5. Deliver the collection receipt. POST /compliance/collection-receipts/{id}/deliveries carries deliveryType receipt, recipientPartyId, medium and deliveredAt. Whoever handed over a vehicle receives the receipt verifiably — in a special case too.

curl -X POST \
  -H 'X-Api-Key: <API_KEY>' \
  -H 'X-Compliance-Organisation-Id: <ORGANISATION>' \
  -H 'If-Match: "<etag>"' \
  -H 'Idempotency-Key: eignerlos-weiterleitung-0417' \
  -H 'Content-Type: application/json' \
  -d '{"targetAtfFacilityId":"<facilityId>","plannedTransferAt":"2026-09-15T08:00:00Z"}' \
  'https://api.tapinomahub.com/compliance/cases/<id>/ownerless-routing'

What you end up with

In the end every special case has its evidence: the impermissible intake with its safeguards, the owner search with its attempts, the disposal with its person, the ownerless vehicle with its target facility and the person handing over with their receipt.

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.