Use a plate when your user has a plate
A registration plate plus its Australian state is a useful starting point for a listing, service request or operational record. Ask the user to select the state rather than guessing it. Keep the entered input available for review and allow corrections.
Use a VIN when you already hold one
The lookup core detects an input that matches its 17-character VIN pattern and selects the VIN route. For RapidAPI, send either input in regoOrVin. For MCP or x402, the field is named plate and also accepts a VIN. A state is optional for a VIN.
Normalize the request, not the evidence
Trim whitespace and use uppercase state codes. Treat the returned search as the lookup input, while vin is a result field that may be unavailable. Do not assume they are always identical or substitute one for the other without checking your workflow.
Read confidence before you prefill
A catalogue result and an identity parsed from a provider description can have different completeness. Inspect _meta.source, _meta.confidence and any _meta.reason. Confidence is a provider label, not a calibrated match probability. Give users a chance to confirm important vehicle details.
Handle no match and service errors separately
The RapidAPI-compatible vehicle response can be HTTP 200 with null fields and a reason in _meta. Gateway, authorization and rate-limit failures still use HTTP error statuses. MCP and x402 have their own status and retry rules. Use the route-specific error guide.
One schema does not mean every field is guaranteed
Fields such as make, model, VIN, body and transmission depend on the available provider data. Vehicle valuations and owner details are outside the current response. Review the data boundaries before designing your interface around a field.