A vehicle catalog API for workshop, fleet and invoicing software

You build software that garages, fleets, tradies or dealers run their day on: workshop management, job cards, invoicing, a DMS, fleet tracking, a service book app. Somewhere in it there's an Add vehicle screen, and every report, reminder, price and parts order downstream depends on what gets typed there.

If that's a free-text field, you already know the cost: "Hilux", "HILUX 2.8", "toyota hilux" as three vehicles, reports that don't add up, and a support ticket every time a customer abroad can't find their car. You need a canonical make and model on every record, for every country your customers are in.

What you get

• One canonical id per model, like car/toyota/hilux, stable across releases. When a model is renamed or merged, the old id stays in former_ids on the model that replaced it, so ids you stored last year still resolve.
• Every country your customers work in. The catalog comes from the national vehicle registers of these countries, New Zealand, Australia, the UK, Germany, Spain and Malaysia among them, and each model says where it's registered and how popular it is there. Filter the picker to the customer's country and the common vehicles come first.
• Cars, vans, trucks and buses in one scheme, plus motorcycles and mopeds, so fleet and freight software doesn't need a second source for the Scania R Series or the Mercedes-Benz Sprinter.
• Body types for cars, aliases (the Golf answers to "Rabbit"), and the years each model is on record.

Sync once a night, not on every page view

The most common mistake we see is calling /makes on every screen load. It works, but it's slow for your users and wasteful for you. Instead:

curl https://vehiclesdb.com/api/v1/catalog \
  -H "Authorization: Bearer vdb_pk_YOUR_KEY" \
  -H 'If-None-Match: "<the ETag from last night>"'

GET /api/v1/catalog returns every make with every model in one gzipped response, costs 0 credits, and is ETagged on the dataset version, so a night when nothing changed costs a 304. Store it in your own table, serve your picker from it, and you're independent of our uptime. The API reference documents the response.

Rather not call an API at all? The same list is free with an account as CSV, JSON, Parquet or SQLite, and Ruby apps can use the vehicles gem, which ships the whole catalog inside the gem, offline.

Clean the records you already have

Years of free-text vehicles in your database? The resolve endpoint takes each string and returns the canonical id with a confidence score and the reason it matched:

curl -X POST https://vehiclesdb.com/api/v1/resolve \
  -H "Authorization: Bearer vdb_sk_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"input": "vw golf"}'
# match.id => "car/volkswagen/golf"

Run it once over your archive, keep the ids, and new records go through the picker. Resolve calls use credits; the car API page has the details and the pricing page the plans.

What we don't do (yet)

We publish the vehicle's identity, not its service data: no VIN decoding, no oil specs or service intervals, no tyre sizes, no recalls, and no plate-to-vehicle lookups. We do publish plate formats so you can validate a plate field. Generations, engines and trims are on the roadmap. If one of those is what your customers ask for most, tell us; it decides what we build next.