posted 2026-07-26 · vindex.vin/blog/map-vehicle-id-between-chrome-kbb-edmunds-vpic
How do I map a vehicle ID between Chrome, KBB, Edmunds, and vPIC?
Vindex maps each provider's vehicle ID onto one YMMTS spine and to each other, with coverage reported per provider pair — so one provider's ID resolves into another's.
You map a vehicle ID between providers by resolving each provider's identifier onto one shared spine and reading the mapped identifier out the other side. Vindex does exactly that: it lands the vehicle on a single YMMTS spine — year, make, model, trim, style — and maps Chrome's, KBB's, Edmunds's, EVOX's, vPIC's, and every other provider's identifier onto that spine and, through it, to each other. Name the identifier you hold and the target provider, and the answer is that provider's identifier for the same vehicle, scored, in either direction — with coverage reported per provider pair. Where a pair has no verified mapping, the answer is the gap, not a guess.
Why you can't just string-match the trim
The reason this is hard — and the reason string-matching trim names quietly corrupts a dataset — is that the industry's catalogs never shared an identifier. The same physical car is a style at one provider, a vehicle at another, a pattern at a third, each under its own key, its own trim string, its own grain. "SE," "SE w/ Convenience Package," and a bare pattern code can all describe the same build across three catalogs, and none of them join on the label. Match on the string and you'll price a decoded VIN against the wrong valuation row, bind a listing's style to the wrong imagery key, or drop options at the provider boundary. The join has to happen on a resolved identity, not on text that merely looks alike.
Vindex resolves the identity first, then maps. That ordering is the whole method.
The spine, and why it's a hub not a mesh
The spine is the YMMTS hierarchy every provider's catalog is ultimately describing, even when each describes it in its own codes:
| layer | what maps |
|---|---|
| spine | year · make · model · trim · style — the hierarchy every catalog describes |
| vehicle IDs | each provider's identifier for the spine row, a sameAs edge — never a blind join key |
| trim & style codes | each provider's trim and style equivalences, pair by pair |
| color codes | factory and provider color codes, cross-walked |
| option codes | option and package equivalences, where the pair is mapped |
The structural payoff is the hub. Without a shared hub, reconciling n providers means maintaining n·(n−1)/2 separate hand-kept crosswalks — every provider paired against every other, each map its own maintenance burden. On the spine, each provider maps once — n edges — and every pair resolves through the hub. You maintain the edge from a provider to the spine; you never maintain the edge from that provider to each of the others directly. That is the difference between a mesh you can't keep current and a hub you can.
How the mapping reads, step by step
- Resolve. Hand the VIN to the address at
vindex.vin/{VIN}and it lands on the spine row. You get the identity manifest — every known provider ID for this vehicle, each stated as evidence: value, source, timestamp, and verification state, with a confidence number on the edge. The VIN itself has a ceiling — it decodes to a pattern, and a pattern can end above trim. Where that ceiling holds, Vindex enumerates the candidate styles and scores them rather than picking one silently. - Map. Name the target provider and read out its identifier for the same spine row — Chrome ID to KBB vehicle, Edmunds style to vPIC pattern, in either direction. Each answer carries its score. Where the pair has no verified mapping, you get the gap stated as a gap.
- Join. Join your own datasets on the mapped identifiers. The join is checkable because every edge it rode carries its source and timestamp — the record did the reconciliation, and you can audit each hop.
Coverage is reported, never asserted
No coverage figure here is hand-written. The coverage manifest renders per provider pair, per model year: which styles are mapped, the confidence distribution across those edges, and the last-verified date. An unmapped cell renders as unmapped — absence is stated, never hidden. So when you ask "does Vindex map Edmunds to vPIC for this model year," the answer is the actual state of that cell, not a marketing number. A mapping appears only once it's verified, carrying its timestamp; confidence stays a number on the edge, never an adjective.
What it costs, honestly
Reading the spine, the mapping structure, and the coverage manifest is free — $0, no account. That's the own-data-first face: the structure that tells you what resolves to what reads without charge. Per-resolution — one identifier in, one out, scored — is priced at the address or stated as absent. The pair table and full-map licensing clear through the catalog: data.vin posts the license and the price, and delivery rides the API. Provider names are stated nominatively — each mark belongs to its owner; Vindex maps between catalogs, it does not republish them, and what each provider's license permits is stated before any mapped ID transacts.
That is the precision ladder in its ID-mapping form: the structure free, the resolution priced, the licensed cross-walk cleared through the catalog — never given away, never invented.
Where to go next
- vindex.vin — resolve a VIN to its identity manifest and read every provider ID mapped to it.
- data.vin — the pillar door: the crosswalk cataloged with its coverage, license, and price.
- specs.vin — the spine's factory numbers for the resolved vehicle: dimensions, powertrain, capacities.
The record, at its other addresses
- data.vinThe pillar door: the crosswalk is a catalog product — coverage, license, price, posted.
- apis.vinThe HOW: one key, one MCP server — the same crosswalk, machine-read.
- specs.vinThe spine's factory numbers for any VIN — dimensions, powertrain, capacities, posted.
- build.vinThe as-built record for any VIN — the option codes the crosswalk maps, as the factory ordered them.
- listings.vinThe live-listings spine — the decode and slug grammar the YMMTS hierarchy serves.
- all.vinEvery door, one record: all.vin/