VIN Decoder API — what vPIC gives you free, and what it cannot

"VIN decoder API" gets typed by developers solving two problems that have almost nothing in common. The first is decoding: take seventeen characters and read back what the plant built. That information is carried by the characters themselves, which is why a decoder is fundamentally a lookup rather than a database of individual cars.

The second problem is history: what happened to this specific car after it left the line. None of that is in the VIN. BJA sets out what the federal history layer holds — "Prior to purchasing a vehicle, NMVTIS allows consumers to find information on the vehicle's title, most recent odometer reading, brand history, and, in some cases, historical theft data." Those records are written later, by states, in response to titling events, and they live in the systems the states feed.

That difference decides your architecture and your budget. The first job costs nothing and can run over every row of an inventory feed. The second is licensed, billed per report, and worth pulling only at the moment a decision depends on it.

NHTSA publishes vPIC as an open service. The batch decoder lives at https://vpic.nhtsa.dot.gov/api/vehicles/DecodeVINValuesBatch/ and caps a single request at 50 VINs. No API key is required. There is no account to create, no plan to pick, and no invoice at the end of the month.

That is the appeal, and it is also the shape of the risk. A keyless public endpoint is a dependency you do not own and have no commercial relationship with — there is no contract behind it and nothing to escalate through. Treat it accordingly: your own retry and back-off behaviour is the only lever you have, so build it deliberately rather than hammering a public service when something goes wrong.

Two habits follow directly from the cap. Batch to it instead of issuing one request per VIN — fifty VINs in one call is the difference between a handful of requests and thousands for the same inventory feed. And cache what comes back, keyed by VIN: a decode describes how the car was built, which is precisely the part of the story that does not change afterwards.

Brands are not a manufacturer concept at all. BJA defines one as follows: "A “brand” is a descriptive label that states assign to a vehicle to identify the vehicle's current or prior condition, such as “junk,” “salvage,” “flood,” or another designation." A state assigns it, after the fact, in response to a titling event. No decoder can derive it from a VIN, and any product that implies otherwise is misleading its users.

The same holds for the rest of what BJA says NMVTIS lets a consumer find before a purchase — the vehicle's title, the most recent odometer reading, brand history, and in some cases historical theft data. Every one of those is a record about this individual car, not a property of its build.

So if your feature is "normalise this inventory feed into year, make and model", vPIC is the entire answer and you can stop reading here. If your feature is "tell the user whether this car is worth buying", the decode is the cheap part and the expensive part is still ahead of you.

The National Motor Vehicle Title Information System is described by BJA as a system "designed to serve as a national repository of vehicle brand information". Reselling from it is not open: providers are approved, and BJA publishes the list. The page introduces it with this sentence — "The following is a list of ALL businesses approved to provide NMVTIS vehicle history reports to public and commercial consumers. Some businesses are affiliated with a primary Approved NMVTIS Data Provider."

Under the heading covering both commercial and public customers, BJA lists twelve approved providers. Read on 2026-09-12, they are:

Tooling that assumes every entry on that page ends in .com will mangle this list: Titlecheck.us carries an uncommon suffix, and VinReport is printed with no suffix at all. One further uncommon suffix appears on the page, VinCheck.Info — but that one belongs to the owned-site group in the next section, not to this list.

The BJA page nests owned websites underneath the provider that owns them. Flatten the HTML to plain text and the nesting vanishes — every name becomes a sibling, and owned sites get promoted into the provider list. The count comes out too high, and a shortlist built from it contains entries that are not separately approved at all. Earlier drafts of this page were built from a flattened copy and came out with the wrong count, which is why the list above was parsed from the page's actual structure.

There are eight such websites, owned between five of the twelve providers. BJA records each as an additional website owned by an approved provider; they sell reports containing NMVTIS data under the parent's approval, which is a legitimate arrangement and simply not the same thing as being approved:

VinGurus.com, Vininspect.com, Recordsfinder.com, StateRecords.org and VinCheck.Info are the ones most often miscounted, so check them by name before a vendor list goes anywhere. And never add the groups together: twelve approved providers, eight owned websites, and the commercial-only links in the next section are three different things printed on one page. A total built by summing them describes nothing that exists.

BJA keeps a second, separate heading for commercial customers only. Six links sit under it: OneAIB.com, add123.com, CARFAX.com, Vitu.com, Experian.com and Yassi.com. Beside CARFAX.com the page prints a parenthetical — "CARFAX offers NMVTIS data to commercial customers in California only".

For anyone building a consumer-facing product, the governing sentence is this one, verbatim from BJA: "Consumers CANNOT receive NMVTIS Vehicle History Reports from Carfax, DMVDesk, or Experian; these entities provide information only to car dealerships." Three entities, named by the agency, supplying dealerships only.

Read that sentence for exactly what it says. It is about who may receive an NMVTIS report, not about whether those companies hold NMVTIS data — Carfax participates in NMVTIS. What it cannot do is sell you, a consumer, that report. Paraphrasing this into "Carfax has no NMVTIS data" is false, and it is the kind of claim that gets a page taken down.

The practical consequence for architecture is concrete: if your product serves the public, the links filed under the commercial-customers-only heading are not a route to your users, however good the integration looks.

BJA is blunt about the problem NMVTIS exists to solve: "Vehicles that incur significant damage are often branded “junk” or “salvage.” Currently, motor vehicles with brands on their titles can without much difficulty have their brands “washed” (i.e., removed) from the titles." It cites Experian Automotive reporting that "in just the first six months of 2008 there were more than 185,000 titles that were initially branded in one state, and then transferred and re-titled in a second state in a way that resulted in issuance of a purportedly clean title."

The agency's own illustration is Hurricane Katrina, after which "authorities reported truckloads of flooded vehicles being taken out of Louisiana to other states as far away as the upper Midwest, where they were dried out, cleaned, and readied for sale to unsuspecting consumers in states that do not brand flood vehicles."

The fix is permanence across state lines: "Through NMVTIS, once a vehicle is branded by a state motor vehicle titling agency, that brand becomes a permanent part of the vehicle's NMVTIS record." That permanence is the reason the brand layer is worth licensing rather than approximating — a clean-looking title in the second state is exactly the failure mode the record is there to catch.

There is a data-modelling lesson sitting in the BJA text that is easy to miss. NMVTIS is "designed to collect information from states, but not to change the nomenclature used in, or standards created by, state motor vehicle laws or by state motor vehicle titling agencies", and "Each state has its own laws, standards, and terminology that are unaffected by NMVTIS."

So do not flatten brand strings into a tidy enum and throw the original away. Store what the record actually says, along with the state that said it, and let your interface group loosely rather than letting your database discard the detail. A label your code did not anticipate is information, not a parsing error.

This matters most at the join. If you are mapping brand text onto your own condition taxonomy, that mapping is a display concern and belongs in a layer you can revise. The stored record should stay as it arrived.

Pay for history when a decision rides on it. If your software helps someone appraise, price, buy, list or arbitrate a specific used vehicle, the title and odometer layer is the part that changes the answer, and the decode is just the label on the row.

Stay free when the job is cataloguing. Normalising a feed, populating a filter, rendering a spec sheet, grouping inventory by model year — the decode covers all of it, at no cost, for as many VINs as you can batch.

The middle case is the one people get wrong: pulling history for every vehicle in a feed at ingest. Decode is free and history is not, so treating them as one pipeline stage means paying for reports on cars nobody ever looked at. Split the stages, and fire the paid call at the point of decision.

A call returns structured JSON: the decode, title brands, odometer readings, theft records and open recalls, plus a link to a downloadable PDF of the report. That is the shape you build against — the JSON for your product's own interface, the PDF for the document a buyer or a customer expects to be handed.

Pricing is $5 for an on-demand report, and $1–$3 per report at committed bulk volume. The single consumer report on the site is $14.99.

Access is by request. There is no self-serve signup — you tell us your expected volume and what you are integrating, and sandbox and production keys are issued on request, so you can build against the sandbox before anything is billed.

CarCheckerVIN is not an approved NMVTIS data provider. We are not on the BJA list and we do not claim to be. Our reports are sourced from ClearVin (clearvin.com), which is listed by BJA among the twelve providers serving both commercial and public customers.

That distinction is legal rather than stylistic, and it is the single most useful question to put to any vendor you are evaluating. A reseller is not an approved provider; an owned website is not an approved provider either, though it sells under its parent's approval. Both arrangements are legitimate. What is not legitimate is a vendor blurring which one it is.

If a vendor is vague about that relationship, ask them to name their upstream approved provider in writing, then check the name against the list yourself.

The pattern that holds up is a two-stage pipeline. Decode at ingest, batched to the 50-VIN cap, and store the result keyed by VIN — you never need to decode the same VIN a second time. Then pull history on demand, at the appraisal or listing step, where a person is about to act on it.

History does not behave the way a decode does. Records are added as states write them, so a report you pulled months ago is a snapshot rather than a permanent answer. Decide deliberately how long a stored report stands before you re-pull it, and show the buyer the date it was run.

Two smaller things that cause support tickets later. Keep the PDF link attached to the deal record rather than regenerating it, so the document a customer was shown is the document you can produce afterwards. And handle rows that came back incomplete explicitly at ingest, rather than letting a half-filled row flow into a join and match the wrong vehicle quietly.

Most of the questions worth asking are answered on one government page, free, before you talk to anybody. The rest are answered by a sandbox key. Work through them in this order.

Then re-read the source page yourself. We read it on 2026-09-12 and the counts on this page reflect that reading. Approvals are added and removed over time, and a list you copied a year ago is a list to re-check before you cite it.