Network Programming in .NET

If you’ve ever built or maintained a parts catalog — brake pads, spark plugs, filters, wiper blades, anything model-specific — you already know the hardest part isn’t storing the data. It’s matching a customer’s vehicle to the right SKU.

This is the fitment problem, and it’s harder than it looks.

Why fitment matching is deceptively hard

A parts catalog usually stores compatibility as structured data: make, model, generation, year range, engine code. That part is fine — it’s exactly the kind of data a vehicle registration lookup returns cleanly.

The hard part is the other side of the equation: what the customer actually types. In the real world, that’s rarely a clean match to your structured fields. People type:

• “Skoda Fabia” — no year, no engine, no generation
• “2016 Skoda Fabia 1.2 TSI” — precise, but phrased differently than your catalog’s fitment string
• “Opel Corsa” — when your catalog, sourced from a UK supplier, only lists “Vauxhall Corsa” (same car, different badge, depending on market)
• “VW Polo” — when the real question is which generation of Polo, because the answer changes the SKU

Traditional approaches — exact string matching, dropdown selectors, SQL LIKE queries — handle the first case fine and fall over on the rest. You either build an enormous manual mapping table (badge names, generation aliases, regional naming quirks) or you accept a worse search experience and push the ambiguity onto the customer.

A different approach: let a language model do the matching

The insight here isn’t “use AI to know about cars.” It’s narrower and more reliable than that: keep your fitment data as the source of truth, and use a language model purely as a fuzzy matcher between what the customer typed and what your catalog already says.

That distinction matters a lot in practice. Asking an LLM to recall precise technical specs (exact torque values, exact part numbers) is a recipe for hallucination. Asking it to reason about whether “Opel Corsa” and “Vauxhall Corsa D” refer to the same car — a fact any experienced parts counter person would know instantly — is a much safer, much more tractable task. The model isn’t inventing anything; it’s doing the kind of common-sense normalization a human would do at the counter.

Why on-device (Chrome’s built-in Gemini Nano) specifically

Chrome now ships a local language model — Gemini Nano — accessible directly in the browser via the Prompt API, with no server round-trip and no API key. For a fitment-matching use case, that has some genuinely useful properties:

• Zero marginal cost per search. No inference bill per catalog lookup, which matters a lot at scale for a high-traffic parts store.
• No data leaves the browser. The customer’s search and your catalog snippet stay local — relevant if you’re matching against commercially sensitive supplier data.
• Works offline / on flaky connections, which is a nice property for a trade counter or a warehouse app running on unreliable mobile data.
• Fast enough for interactive search — this isn’t a background batch job, it’s a live filter-as-you-type experience.

The trade-off is that Gemini Nano is a small model. It won’t out-reason a frontier model on genuinely obscure technical trivia. But for the kind of common-sense normalization fitment matching actually needs — generation aliases, badge equivalence, rough year-range reasoning — that’s well within a small model’s capability, and it’s worth proving that out before assuming you need a heavier (and costlier) server-side model.

The demo

I built a small working demo of this: marvelous-liger-5c793b.netlify.app

It mocks the whole flow end to end:

1. Step 1 — registration lookup (simulated). Type or click a fake number plate, get back a vehicle record (make, model, year, engine) — standing in for a real reg-lookup API call.
2. Step 2 — fitment filter (real inference). That vehicle description is matched, live, against a small catalog of brake pad SKUs — each carrying structured fitment data (platform, generation, year range, engine) — using Gemini Nano running entirely in your browser.

A few deliberately awkward test cases are built in, specifically to check whether the model is reasoning or just pattern-matching:

• Typing “Skoda Fabia” with no year correctly surfaces parts across all three Fabia generations in the catalog.
• Typing “2016 Skoda Fabia 1.2 TSI” correctly narrows that down to the one generation it actually fits.
• Typing “Opel Corsa” correctly matches a catalog entry that only ever says “Vauxhall Corsa” — nowhere on the page or in the underlying data does the word “Opel” appear. The model has to know, from general knowledge, that Opel and Vauxhall are the same car under different regional badges (Vauxhall in the UK/Ireland market naming, Opel everywhere else in Europe). Typing “Opel Astra” — a real Opel model with no equivalent in this catalog — correctly returns nothing, ruling out a lucky blanket association.

That last case is really the crux of the demo. A keyword search could never make that connection unless someone manually added an alias table entry for every badge-engineering pair across every market. The model does it for free, because it’s reasoning about the underlying vehicle rather than matching text.

Where this is genuinely useful — and where to be careful

Good fit:

• Free-text “what’s my car” search boxes on a parts catalog, replacing rigid make/model/year dropdowns
• Normalizing incoming customer descriptions before hitting a structured fitment database
• Client-side pre-filtering of a large catalog before a final, precise server-side lookup

Worth being careful about:

• Don’t let the model be the only check on a safety-critical fitment decision (brakes, tyres, anything where an actual wrong-fit part is dangerous) — treat its output as a shortlist, then validate against exact structured fields (year within range, engine code match) before confirming a sale.
• Small on-device models can occasionally drift off the expected output format — build in parsing that degrades gracefully rather than assuming a perfectly clean response every time.
• Availability depends on the user’s Chrome version, flags, and device capability (the model needs to download once on first use) — this is a progressive enhancement, not something to rely on as your only search path yet.

Try it yourself

The demo is live at marvelous-liger-5c793b.netlify.app — open it in a recent Chrome build (chrome://flags/#prompt-api-for-gemini-nano enabled), type a vehicle into the reg-lookup box or the fitment search directly, and watch it reason through generation and badge differences in real time, entirely on your own machine.

Technical appendix: how the JavaScript works

Everything runs client-side, in a single HTML file, with no backend. The interesting part is a small, generic aiFilter() function — it knows nothing about cars or brake pads specifically, and could just as easily filter a product catalog, a document set, or a list of job candidates against any natural-language criteria.

1. Feature detection and session setup

The Prompt API is exposed as a global LanguageModel object in current Chrome builds. The first step is just checking it exists, then checking on-device model availability before creating a session:

function getPromptAPI() {
  if ('LanguageModel' in self) return self.LanguageModel;
  if (self.ai && self.ai.languageModel) return self.ai.languageModel; // older API surface
  return null;
}
async function createFilterSession(onStatus) {
  const api = getPromptAPI();
  const availability = await api.availability(); // 'available' | 'downloadable' | 'unavailable'
  if (availability === 'unavailable') throw new Error('Gemini Nano not available on this device.');
  return api.create({
    expectedOutputLanguages: ['en'],
    monitor(m) {
      // fires progress events the first time the model needs downloading
      m.addEventListener('downloadprogress', (e) => onStatus(`Downloading: ${Math.round(e.loaded * 100)}%`));
    },
    initialPrompts: [{ role: 'system', content: '...instructions below...' }],
  });
}

A system prompt is set once, at session creation, rather than repeated on every call. It tells the model exactly what shape of task this is and exactly what shape of answer to give back:

“You are a precise fitment-matching engine… match generously but sensibly: account for generation nicknames, platform-sharing and rebadging between related manufacturers… Reply with ONLY a comma-separated list of the item numbers that are compatible. No explanations.”

That last constraint matters more than it looks. Small on-device models are far more reliable at producing a short, tightly-constrained output (a list of numbers) than at producing well-formed free text or JSON — so the whole design leans on getting the model to do the minimum possible amount of “talking.”

2. One batched prompt, not one call per item

Rather than asking the model “does item 1 fit? does item 2 fit?” — N separate inferences — the whole catalog is serialized into one numbered list and sent in a single prompt:

const list = items.map((item, i) => `${i + 1}. ${describe(item, i)}`).join('\n');
const prompt =
  `Customer vehicle: "${criteria}"\n\n` +
  `Catalog items:\n${list}\n\n` +
  `Which item numbers are compatible with the vehicle "${criteria}"? ` +
  `Respond with only the comma-separated numbers (e.g. "1,3,5") or "none".`;
const raw = await session.prompt(prompt);

The describe() function is the only thing that’s catalog-specific — it’s a small callback that turns one item into a line of text the model reads. For the brake pad demo it’s just part name + fitment string; for a different catalog it’d read different fields entirely. This is what makes aiFilter() reusable rather than one-off.

3. Parsing the response back into real objects

The model’s reply is a plain string like "1,3,7" or "none". Parsing deliberately doesn’t assume a perfectly clean format — it just pulls out any digits present, which degrades gracefully if the model adds stray words despite instructions not to:

const matchedIndexes = new Set(
  (raw.match(/\d+/g) || []).map(n => parseInt(n, 10) - 1)
);
const kept = items.filter((_, i) => matchedIndexes.has(i));

Those indexes map straight back to the original array, so the function returns real catalog objects — not text the model generated — which is what keeps the model firmly in a matching role rather than a data generation role. It never gets the chance to invent a SKU or a fitment string; it only ever gets to point at ones that already exist.

4. Loading the model once, not per search

The first version of this demo created and destroyed a session on every click, which meant a delay on the very first search while the model loaded. The current version preloads a single session as soon as the page opens — the “Find compatible parts” button stays disabled with a spinner until createFilterSession() resolves — and that same session is reused for every subsequent search, so only the very first page load pays any loading cost.

5. The registration lookup is the one part that’s fake

Worth being explicit: Step 1 (plate → vehicle) in the demo is a hard-coded lookup table with an artificial setTimeout delay, standing in for what would be a real API call in production — e.g. against a vehicle registration dataset like the ones we work with at carregistrationapi.ie. Step 2 (the actual fitment filtering) is the only part doing real inference, and it’s a self-contained function that would drop into any catalog UI unchanged.

If you’ve ever tried to decode a Chinese VIN or look up vehicle specifications for a car manufactured in China, you’ll know the data is hard to come by. Commercial providers charge significant fees, the official sources are in Chinese, and the coverage is often incomplete. I recently spent several weeks solving this problem from first principles — scraping, parsing, and enriching the entire MIIT vehicle type approval database — and the result is now available as a data download.

Here’s how it was built, what’s in it, and why it might be useful to you.

What is the MIIT Gonggao system?

In China, every vehicle model that can be legally manufactured and sold must first be approved by the Ministry of Industry and Information Technology (MIIT). These approvals are published in batches called 公告 (Gonggao — literally “announcements”) through the Road Motor Vehicle Manufacturers and Products system (道路机动车辆生产企业及产品).

Each Gonggao entry represents a single approved vehicle variant, with a unique model code such as SGM7102JBA1 (a Buick sedan made by SAIC-GM) or TSL7000BEVAR4 (a Tesla Model Y built in Shanghai). The MIIT database is the authoritative registry of every vehicle permitted for manufacture in China — domestic brands, international joint ventures, electric vehicles, commercial trucks, buses, motorcycles, everything.

The data is public, but it’s fragmented across hundreds of batch announcements, buried in a query interface that’s entirely in Chinese, and has no bulk download option.

How the database was built

The MIIT provides a query API at service.miit-eidc.org.cn that powers their web interface. By reverse engineering the API calls made by the search page, it’s possible to query programmatically.

The collection process ran in two phases:

Phase 1 started with an existing seed list of known Gonggao codes and fetched their full technical specifications — dimensions, weight, engine details, VIN prefix, emission standard and so on.

Phase 2 ran a systematic scan through all two-letter prefix combinations (AA through ZZ), effectively enumerating the entire active catalogue. This discovered tens of thousands of models not in the seed list. Prefixes like CA (FAW/Jiefang) returned over 8,000 records alone.

The final collection covers 227,000+ vehicle records across all vehicle categories.

English make and model enrichment

The MIIT data is entirely in Chinese. Brand names like 别克(BUICK)牌 are recognisable to a Western reader, but most domestic Chinese brands are not. Vehicle types are bureaucratic category names (纯电动运动型多用途乘用车 = pure electric SUV) rather than marketing model names.

To make the data usable for an international audience, every record was passed through the Claude AI API using the Batch API at roughly $2.50 for the full 191,000-record run. The prompt provided the Chinese brand name, vehicle type, manufacturer name, dimensions, wheelbase and VIN prefix, and asked for the English make, model name and a confidence level.

The results are stored in EnglishMake, EnglishModel and EnglishConfidence fields. For well-known brands the accuracy is very high — Tesla, Toyota, BMW, BYD, Volkswagen, Geely and hundreds of others are correctly identified with high confidence. For obscure domestic commercial vehicle manufacturers, the model name may be generic (e.g. “Heavy Duty Tipper Truck”) but the make is generally correct.

VIN prefix data

One of the most useful aspects of the dataset is the IdentificationCode field, which contains the VIN prefix or prefixes assigned to each approved model.

A Chinese VIN follows the global standard: the first three characters are the World Manufacturer Identifier (WMI), and characters 4–8 are the Vehicle Descriptor Section (VDS) which identifies the specific model variant. The MIIT records the approved VIN prefix for each Gonggao entry, typically eight characters followed by placeholder characters (e.g. LRW3E7FA×××××××××).

This means the database can function as a Chinese VIN decoder: given any VIN from a Chinese-market vehicle, match the first 8–11 characters against the prefix table to identify the make, model, fuel type, dimensions, emission standard and production details.

For example:

• LRW3E7FA → Tesla Model Y, 特斯拉(上海)有限公司, pure electric SUV, Shanghai
• LSGEP83A → Buick sedan, 上汽通用(沈阳)北盛汽车有限公司, 999cc petrol engine, National VI emissions
• LFV2A2AD → Volkswagen Lavida, 上汽大众汽车有限公司, 1.5L petrol

What’s in the download

The dataset is a single UTF-8 CSV file containing 227,000+ rows with the following fields:

Model — Gonggao model code — the official Chinese type approval identifier

Make — Manufacturer name (Chinese)

Brand — Brand/marque name (Chinese)

Type — Vehicle category (Chinese)

EnglishMake — Manufacturer name in English (AI-resolved)

EnglishModel — Model name in English (AI-resolved)

EnglishConfidence — Confidence level of English translation: high / medium / low

CompanyName — Full legal name of the manufacturing entity

EnterpriseAddress — Factory and production address

VehicleLength / VehicleWidth / VehicleHeight — Overall dimensions (mm)

Wheelbase — Wheelbase (mm)

KerbWeight — Kerb weight (kg)

TotalMass — Gross vehicle weight (kg)

MaxSpeed — Maximum speed (km/h)

PassengerCapacity — Approved seating capacity

FuelType — Fuel type (gasoline, electric, diesel, hybrid, hydrogen, etc.)

EmissionStandard — Emission standard (National III through National VI)

TireSpecs — Tyre size specifications

IdentificationCode — VIN prefix(es) for vehicle identification

Who is this for?

Automotive data businesses building VIN lookup APIs, vehicle history services, or parts fitment databases for the Chinese market. The VIN prefix data in particular is expensive to license commercially — this dataset provides a solid foundation at a fraction of the cost.

Researchers and analysts studying the Chinese automotive market — EV adoption rates, manufacturer market share, emission standard transitions, the rise of domestic brands versus joint ventures.

Parts and aftermarket businesses who need to match vehicle specifications to the correct components for Chinese-market vehicles.

Developers building applications for the Chinese automotive sector who need a structured, machine-readable vehicle reference database.

Limitations

The dataset reflects the MIIT active catalogue at the time of collection. Discontinued models that have been removed from the active catalogue are not included. The English make/model enrichment is AI-generated and should be treated as indicative for low-confidence records — the underlying Chinese fields are always authoritative. VIN prefix matching identifies the approved model family but may return multiple variants for a given prefix, as multiple trim levels can share a VIN prefix range.

Get the data

The full dataset is available for download at payhip.com/b/3S6PE.

The CSV is compatible with Excel, Google Sheets, Python (pandas), R, SQL Server, MySQL and any standard data tool.

We’re delighted to announce that our vehicle registration lookup service now supports Indonesia. With over 150 million registered vehicles on its roads, Indonesia is one of the largest automotive markets in Southeast Asia, and adding it to our coverage has been a long-running priority. As of today, you can query Indonesian plates through the /CheckIndonesia endpoint.

What you get back

Every successful lookup returns the core vehicle attributes you’d expect: make, model, year of registration, engine displacement, body type, colour, and fuel type. Where the underlying regional registry exposes them, we also surface the VIN (chassis number), the STNK (registration certificate) expiry date, the next tax due date, and the outstanding tax amount in Indonesian rupiah.

Here’s a representative response for plate PA1554RE:

json

{
   "Description": "SUZUKI ERTIGA",
   "RegistrationYear": "2017",
   "CarMake": "SUZUKI",
   "CarModel": "ERTIGA",
   "BodyStyle": null,
   "EngineSize": "1373",
   "MakeDescription": "SUZUKI",
   "ModelDescription": "ERTIGA",
   "VIN": "MHYKZE81SHJ3XXXXX",
   "VehicleType": "MINIBUS",
   "Colour": "HITAM METALIK",
   "FuelType": "BENSIN",
   "OwnershipNumber": null,
   "StnkExpiry": "2027-10-30",
   "TaxExpiry": "2026-10-30",
   "TotalDue": 2319000,
   "Region": null,
   "Location": "SULAWESI UTARA",
   "ImageUrl": "http://nopol.id/image.aspx/@U1VaVUtJIEVSVElHQQ==",
   "Extended": null
}

A note on Indonesia’s plate system

Unlike countries with a single unified vehicle registry, Indonesia operates a federated model: each province (and sometimes individual regencies within it) runs its own SAMSAT system for collecting road tax and issuing registration documents. The first one or two letters of any Indonesian plate identify the issuing region — B for Jakarta, D for Bandung, PA for Papua, and so on — and behind each prefix sits a different government portal with its own quirks, authentication scheme, and data model.

This is why rolling out Indonesia coverage has been a region-by-region effort rather than a single integration. Every prefix we support represents a separately reverse-engineered pipeline, and the depth of data we can return varies according to what each provincial system exposes.

Current regional coverage

At launch we support nine regions, covering a substantial portion of Indonesia’s vehicle population:

Reading the response fields

A few of the returned fields warrant explanation for users unfamiliar with the Indonesian system:

• FuelType — values are returned in Bahasa Indonesia. BENSIN is petrol/gasoline; SOLAR is diesel; LISTRIK is electric.
• VehicleType — categories use the official SAMSAT classifications: MINIBUS, SEDAN, JEEP S.C.HDTP, SPD. MOTOR R2 (two-wheeled motorcycle), and so on.
• Colour — returned in Bahasa Indonesia. Common values: HITAM (black), PUTIH (white), MERAH (red), ABU-ABU (grey), often suffixed with METALIK for metallic finishes.
• StnkExpiry — the five-yearly registration certificate renewal date.
• TaxExpiry — the annual PKB road tax due date. This is the more frequently relevant of the two.
• TotalDue — the amount payable at the next renewal in rupiah, including PKB, the SWDKLLJ mandatory accident insurance contribution, opsen (provincial surcharge), and any arrears or penalties where applicable.

What’s next

We’re actively working on additional Indonesian regions, with Jawa Tengah (Central Java, prefixes G/H/K/R/AA/AD), Jawa Timur (East Java, L/M/N/P/S/W/AE/AG), Bali (DK) and Sumatera Utara (BB/BK) all on the near-term roadmap. If your use case depends on a specific Indonesian region that isn’t yet listed, get in touch — that kind of feedback is what drives our prioritisation.

The full endpoint documentation is at https://www.nopol.id/api/reg.asmx?op=CheckIndonesia.

Our vehicle API network expands into Taiwan with full motorcycle registration lookups — make, age, engine size, and emissions test history, all in one call.

Taiwan has one of the highest motorcycle densities in the world, with over 14 million registered two-wheelers on its roads. Today, we’re pleased to announce that the /CheckTaiwan endpoint is live — bringing motorcycle registration data from Taiwan’s national vehicle database into our global API network.

What the endpoint returns

A single call to /CheckTaiwan with a Taiwanese plate number returns structured vehicle data covering identity, registration history, and emissions compliance records:

• Make — Manufacturer name (Chinese & romanised)
• Age / Registration year — Year of manufacture and license issue date
• Engine size — Displacement in cc and engine cycle type
• Inspection records — Full emissions test history with HC, CO, and CO₂ readings

Sample lookup: MWN-0076

Here’s what a real response looks like for a 2018 Kymco (光陽) motorcycle:

{
  "Description": "光陽",
  "RegistrationYear": "2018",
  "CarMake": { "CurrentTextValue": "光陽" },
  "EngineSize": "149",
  "ManufactureDate": "01/08/2018",
  "LicenseIssueDate": "05/09/2018",
  "EngineCycle": "四行程",
  "TestRecords": [
    {
      "LicensePlate": "MWN-0076",
      "InspectionType": "定期檢驗",
      "HC_ppm": "102",
      "CO_pct": "0.1",
      "CO2_pct": "14.8",
      "Result": "合格",
      "TestDate": "20240822"
    },
    {
      "LicensePlate": "MWN-0076",
      "InspectionType": "定期檢驗",
      "HC_ppm": "315",
      "CO_pct": "0.1",
      "CO2_pct": "14.9",
      "Result": "合格",
      "TestDate": "20240718"
    }
  ]
}

The TestRecords array is particularly valuable — it provides a full chronological emissions test history, with pass/fail status (合格 = pass), hydrocarbon and carbon monoxide readings, and the serial number of each inspection. This supports fleet compliance monitoring, insurance underwriting, and second-hand vehicle verification use cases.

API endpoint

The endpoint is live now at:

https://www.chepaiapi.tw/api/reg.asmx?op=CheckTaiwan

Full documentation and interactive testing are available at chepaiapi.tw.

Expanding Chinese-language coverage

This launch also deepens our Chinese-language vehicle data coverage. Alongside Taiwan, our mainland China vehicle lookup service at chepaiapi.cn continues to serve customers requiring PRC plate data — together forming a comprehensive Chinese-language API offering across both sides of the strait.

Use cases

The Taiwan endpoint is well-suited to:

• Insurers pricing two-wheeler policies
• Logistics platforms operating scooter fleets
• Used vehicle marketplaces verifying provenance
• KYC and compliance workflows touching Taiwanese vehicle assets

The inclusion of emissions test records is a differentiator that goes beyond simple registration confirmation — providing genuine due diligence depth for any platform that needs it.

Taiwan joins our network of 55+ country vehicle lookup APIs. We’ll continue expanding coverage across Asia Pacific throughout 2026.

Visit chepaiapi.tw to get started →