One car for sale.
One address.

Search. Resolve. Route.

The market lists a car in many places; the VIN names it once. Every venue where the car is listed renders on one page — dealer, auction, private seller — each fact posted: price · venue · source · timestamp. Free. No account.

Hand the hunt to an agent that works for you — you appear only where you are load-bearing, choosing the car and authorizing the close, and everything it does posts to a receipt that survives being shown to you.

Paste the VIN — or type year make model.

A VIN is 17 characters and never uses I, O, or Q — or type year make model.

The listinglistings.vin/7MMVABDM3RN163785

7MMVABDM3RN163785

2024 Mazda CX-50 · decoded from the VIN · check digit 3

Every venue this VIN is listedone row per venue

venuepostedprice
Dealersource · timestamp · verification stateposts live
Auctiona lot is a listing in an auction venue · source · timestampposts live
Private sellersource · timestamp · verification stateposts live

delta vs. market value — a signed number, never an adjective · basis values.vin/7MMVABDM3RN163785

The record behind the listing

The exit is stated: the listing id rides to buy.vin/7MMVABDM3RN163785 — the deal starts from this record.

Figures render live at the address. This page states structure, not prices. Unverified facts read “Reported, not yet verified.”

live listings

2.1M+

the count is a fact, so it posts like one: value · source · timestamp — this one from the brand registry, posted 2026-07-27; the live count posts at the address

venues

dealer · auction · private seller

one spine, one grammar — an auction lot is a listing in an auction venue

posted per listing

price · venue · source · timestamp

verification state on every row — verified, or “Reported, not yet verified.”

Every venue, one field.

Dealer, auction, and private-seller supply sit on one spine, keyed to the same seventeen characters. A listing is a record, not an ad: verified and reported facts are labeled, never blended.

Hunting one car

the by-VIN read

You are not reading a thousand rows; you are resolving one. The car’s page holds every venue it is listed, each price beside its source and timestamp, and the delta against the value spread — then the deal starts from the record.

the price · the delta vs. value · the venue · the verification state

The dealer’s counter

supply on rails

Your inventory is addressable by its numbers, and the buyer who found the car found your car — not a portal’s ad unit. Leads export as ADF — Auto-lead Data Format, the file a dealer CRM ingests — and the lead is yours; the fee posts on the export sheet before you send. Your entrance is dealers.vin.

the listing state · lead export ADF · fee posted on export

The listing a buyer reads is the listing the dealer posted. Same page, both sides.

No VIN yet. Browse narrows to one.

Facets are the way in, not the destination. Every search ends at a seventeen-character address — each result row is a VIN, and opening it opens the car’s page, not an ad.

Browse, resolvingfacets → one VIN

result · one VIN eachpricevenue
year make modelposts livethe venue
year make modelposts livethe venue
year make modelposts livethe venue

Results render live at the address. Every row resolves to listings.vin/{VIN} — the page above. The field takes the same grammar: year make model rides the address bar as year_make_model.

The plan.

01SearchFacets or the field, every venue — a VIN opens the car; year make model narrows to one. Every result is a VIN.
02Resolvelistings.vin/{VIN}: one car, every posted fact — price beside source and timestamp, the delta against the value spread a signed number, unverified facts labeled.
03RouteThe listing id rides to buy.vin for the close, or the record opens first at vhr.vin. A dealer’s lead exports as ADF into their own CRM.

Postedlistings.vin search: $0 · every VIN, every visit · no account

Your agentHand the hunt to your agent: it searches, reads every venue, and routes the deal — you appear only where you are load-bearing: choosing and authorizing. Everything it does posts to a receipt that survives being shown to you.

Questions with posted answers.

Is this every car for sale?
Dealer, auction, and private-seller venues on one spine — an auction lot is a listing in an auction venue. Coverage posts on the page as a fact with source and timestamp; gaps are stated, not hidden.
Why does a price read “Reported, not yet verified.”?
Because the venue posted it and the record has not confirmed it. Verified and reported facts are labeled; they are never blended.
What does it cost?
$0 for search, every VIN, every visit — posted above like every other number. Developer and agent access is metered per call; the rate card posts at apis.vin. A dealer’s lead fee posts on the export sheet before you send.
I’m a dealer — who owns the lead?
You do. Leads export as ADF straight into your CRM. No portal sits between you and the buyer. Your entrance is dealers.vin.
Can my agent hunt instead of me?
Yes. It reads the same page — every venue row, every posted fact — as typed JSON at the same address, and where it acts for you, every step posts to a receipt that survives being shown to you. The machine surface is below.

The listing is one face of the record.

The other addresses read the same seventeen characters.

know the car

do the deal

the dealer's counter — dealers & builders

The same corpus, typed.

Agents read this door the way you do — one VIN resolves to one listing — as typed JSON at the same address. Who buys and who gets the receipt are stated motions.

An agent searches and buys on its own accountb2a.vin
The capability embeds downstream — a dealer’s systems ingest the lead as ADF; the dealer’s entrance is dealers.vin

One MCP server for the whole platform: apis.vin/mcp
Every listing renders as typed JSON at the same address
API access is metered per call · rate card posted at apis.vin

A typed listing, as an agent reads itapis.vin/mcp

// tools/call · search_listings
{
  "type": "vin.listing",
  "vin": "7MMVABDM3RN163785",
  "vehicle": {
    "year": 2024,
    "make": "Mazda",
    "model": "CX-50"
  },
  "venues": [{
    "id": <listing_id>,
    "venue": <"dealer" | "auction" | "private">,
    "price": {
      "amount": <integer, USD cents>,
      "currency": "USD"
    },
    "source": <string>,
    "posted": <RFC 3339 timestamp>,
    "verification": <"verified" | "reported">
  }],
  "exit": {
    "action": "buy",
    "href": "https://buy.vin/7MMVABDM3RN163785"
  }
}

For the agent you send

The agent reads the same record you do. Same two routes, three representations — the numbers never differ between them.

motions: B2A · B2A2D

B2A — the buyer is an agent — no human leaf; discover, bind, pay, worst-case cost posted before the call
B2A2D — the capability embeds downstream — reserved acts route back to a credentialed human leaf

curl https://listings.vin/ -H 'accept: text/markdown'        → the markdown twin of this page
curl https://listings.vin/{VIN} -H 'accept: application/json' → the record as typed evidence objects
curl https://listings.vin/{VIN} -H 'accept: text/markdown'    → the record's markdown twin

Machine surfaces on this host: /llms.txt · /icp.json · /.well-known/agents.json · one estate MCP server — apis.vin/mcp (every door a lens; tool results carry the door URL).

Attribution: X-Client-Type: html | md | json | mcp — read for agent-led demand attribution; it never changes the record.

No gate on this door's two routes — keyless reads, no account. Gated actions elsewhere on the estate return a typed OFFER (posted price · hard ceiling) or a NEEDS_HUMAN handoff, never a dead end.

One car for sale.One address.