Checking recalls before a vehicle or part moves on

A vehicle is due to be sold, a part is due to ship — and nobody knows whether a safety measure is pending for it. In practice this only surfaces when a customer asks or a workshop refuses to release the vehicle. By then the transaction has progressed, and unwinding it costs more than the check would have.

The match runs by series against the recall and safety measures of the official registers. What matters is less the individual hit than the declared data status: an answer without a status is not an answer but a snapshot with no shelf life.

What this case requires

• A vehicle identification number for the vehicle match. It determines series and build period — the reference points the match runs against.
• A list of part numbers for the stock match. The bulk call is meant for inventories, not for single cases in a loop.
• Somewhere to store the data status alongside. Without it you cannot later say how old an answer is.
• A decision on what a hit triggers. Sales block, notice to the customer or inspection order to the workshop — the query does not make that call for you.
• The entitlement to query the vehicle. With the call you confirm that you are the keeper, the owner or demonstrably authorised or otherwise legally entitled, and that you use the identification number solely for the stated permissible purpose.

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. Determine the vehicle. GET /vin/{vin}/vehicle returns series and build period. This stage comes first because a recall almost always attaches to a series and a period, not to one individual vehicle.
2. Match the vehicle. GET /recalls/vehicles/{vin} returns the hits from the official registers, together with the data status per register. No hit is a valid result and not an error — it means nothing was on record as of the stated status.
3. Match the stock. POST /recalls/parts checks up to a hundred entries in positions in one call — each with an oeNumber, optionally your own reference and optionally the vehicle. For an inventory this is the only workable route: anyone querying line by line never checks the whole stock in practice.

curl -X POST \
  -H 'X-Api-Key: <API_KEY>' \
  -H 'Content-Type: application/json' \
  -d '{"positions":[{"oeNumber":"4H0907801","reference":"lager-A12"},{"oeNumber":"8K0959455K","reference":"lager-B07"}]}' \
  'https://api.tapinomahub.com/recalls/parts'

What you end up with

What remains is a documented decision: sell, have it inspected or block — together with the data status it rests on. That is the difference between “we knew nothing” and “we checked as of this status”.

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.