Start
Ask a VIN a question and get back a typed, evidence-carrying answer — one keyless curl first, then five pillar on-ramps that are journey pages.
The whole estate answers one question shape: ask a VIN a question, get a signed answer — typed, evidence-carrying, provenance-labeled. The first call is keyless and free. Run it now:
curl 'https://apis.vin/decode/JM3KFBXY1S0597748'{
"type": "OK",
"decode": {
"vin": "JM3KFBXY1S0597748",
"year": 2025,
"make": "Mazda",
"model": "CX-5",
"retailValue": "35887.00",
"msrp": "43400.00",
"priceCurrency": "USD"
},
"provenance": { "environment": "sandbox" }
}That answer is the estate in one screen: a typed Answer (OK / EMPTY /
BLOCKED / OFFER — never a bare 500, never an empty object dressed as
success), an identity the wire stands behind, money as decimal strings, and
a provenance block that declares its environment and what is simulated. The
full answer also posts trim, body, engine, and an odometer fact — run it and
read them. The anonymous rung is free; the money gate is settlement, never
signup.
The same call, from your terminal
npx apis.vin vehicle.decode --vin JM3KFBXY1S0597748The vin CLI drives the same generated SDK against the
same pinned catalog, so it cannot drift from the wire above. There is no shared
demo key anywhere in these docs — nothing to leak, nothing to revoke. The first
keyed-worthy call mints its own sandbox key — POST /keys, no email, no
approval, no human — stores it locally, and says so on stderr.
A VIN in 60 seconds walks the
full ladder: key → decode → record → deal.
Five on-ramps, one per pillar
Every capability in the catalog stands on one of five pillars — Data, Services, Commerce, Workflows, AI. Each pillar's on-ramp is a journey page, not a separate quickstart: every step names the catalog capability that fulfills it, every snippet runs against the sandbox world as-is, and every shown answer is a deterministic claim you can verify by running the trigger above it. The roster states each journey's status; the rows below repeat it.