ODI complaint record

Each record is a structured incident report: flags and counters for severity, identifiers for the vehicle, free text for what happened.

The cataloged API field list runs from odiNumber (the unique key) through boolean crash and fire markers, numberOfInjuries, numberOfDeaths, dateOfIncident and dateComplaintFiled, to components, summary and a products array identifying whether the complaint concerns a vehicle, tire or piece of equipment. Two privacy rules shape the payload: the vin field holds 'truncated 11-character VIN of the complainant vehicle', and the summary carries 'personal details redacted under FOIA'. So the record links a symptom to a component on a specific vehicle generation without exposing the filer.

Field depth decides how much safety signal you can extract. Crash and fire flags turn a text corpus into classifiable severity data; injury and death counts rank failure modes; the components array enables per-part trend lines without natural-language processing.

The limits matter equally. An 11-character truncated VIN identifies the vehicle line but not the individual unit, which blocks owner-notification style joins by design. Redacted summaries remove personal context, so sentiment or claim verification cannot rely on them. And because records are filed by consumers, component naming varies - a robust pipeline normalizes the components field before counting. Buyers evaluating providers should compare raw field availability rather than dashboard features, since every analytic above is derivable only if the underlying fields ship.

1. Verify the field set. Expect odiNumber, crash, fire, numberOfInjuries, numberOfDeaths, dateOfIncident, dateComplaintFiled, components and summary in each response.

1. Test VIN handling. The vin field is a 'truncated 11-character VIN' - design joins at vehicle-line level, not unit level.

1. Assess redaction impact. Summaries have 'personal details redacted under FOIA'; workflows needing identities must look elsewhere.

1. Use the products array. It distinguishes vehicle, tire and equipment complaints - filter on it for parts-focused analysis.

1. Key on odiNumber. It is the stable identifier for deduplication across repeated API pulls.

The complaint record connects to the campaign system and the edge cases of vehicle identification in NHTSA data.

• automated-traffic-rate-control
• model-year-9999
• nhtsa-campaign-number
• tire-product-entry