Japanese chassis numbers

curl "https://api.cardog.app/v2/chassis/ZRR80-0143041" \
  -H "x-api-key: $CARDOG_API_KEY" \
  -H "Cardog-Version: 2026-10-26"

A vehicle built for the Japanese home market has no VIN. It carries a chassis number (車台番号): a model code, a hyphen and a serial, such as ZRR80-0143041. The code names the maker and a family of models; the serial is a production counter. There is no year in it and no check digit, so a chassis number cannot be decoded the way a VIN can. It can only be looked up.

Our source is the Japanese Ministry of Land, Infrastructure, Transport and Tourism (MLIT). Its recall notices publish, for each model code, the serial ranges a notice covers and the dates those units were built. Its fuel economy list prints the engines each type was sold with. GET /v2/chassis/{chassis} reads both.

Send the number with the hyphen. A hyphen-less number is accepted when exactly one published model code and serial length fits it; otherwise the read is a 400 asking for the hyphen. A 17-character VIN is a 400 pointing at GET /v2/vin/{vin}.

What the read answers

One candidate is one maker. Inside it:

• modelsJa and modelsEn are every model the notices print for the code. A code is a family, so the read says Noah, Voxy and Esquire, not which of the three this unit is. modelsEn names the ones with an English name and is not lined up with modelsJa; modelRefs carries the registry refs for the models that have an entry.
• typeApprovals are every type approval (型式) published for the code. The prefix names the emissions rule the type was approved under, decoded in emissions: the rule, its year, the fuel heading and whether it is a hybrid rule.
• notices are the MLIT notices whose published serial range holds this unit. A unit inside a range is in the notice's scope. Whether the fix was done is not on the record. A notice filed under two type approvals or two model names appears once per range, so group by notification to count recalls.
• built is the build window the notices holding the serial agree on. When no notice holds it, buildBound is what the neighbouring published ranges allow, since serials are issued in order: an outer bound, often years wide. Both are null when the code has too few published ranges to say anything.
• engines are the engines the fuel economy list prints for the maker and code, with the edition years that list them. Several engines means the list alone does not say which this unit has; the type approval on the plate narrows it.

sources names the public records the answer was read from. The read costs 2 credits.

The four statuses

status is the one field to branch on. Each value is a different next move.

Reading the number off a photo

curl -X POST "https://api.cardog.app/v2/chassis/image" \
  -H "x-api-key: $CARDOG_API_KEY" \
  -H "Cardog-Version: 2026-10-26" \
  -H "content-type: application/json" \
  -d '{"image": "<base64 photo>"}'

The number is on the caution plate, a riveted plate under the hood or in the door jamb, and stamped into the frame. POST /v2/chassis/image takes a photo of either as base64 (JPEG, PNG or WebP, 10 MB at most) and answers the number read off it.

links.chassis is the read above, ready to open. typeApproval is the 型式 printed on the plate, which settles the model when the chassis read lists several. When confidence is low, a character was in doubt: readings lists the possible numbers, most likely first, for a person to confirm before anything is written down.

A photo with no legible number is not an error of the request. It is a 200 with read: null and a refusal:

A read costs 2 credits. A refusal costs 0. The answer is never cached.

Keys and sessions

Both reads take an API key. The photo read also answers a signed-in session, so an app can read a plate for a user before it holds a key of its own.