Skip to main content
GET /v1/vehicles/vin/{vin}/live Every other vehicle endpoint answers from the last import. This one goes to the dealer’s website while you wait and returns what it says right now. Use it when staleness is the problem you are solving — a shopper on the phone, a price you are about to quote, a listing you suspect has sold.
A live call is slower and more expensive than a cached read. It is not a replacement for the feed: use the feed for breadth, this for the one VIN that matters this second. If you need a handful of VINs warm before a customer conversation, prewarm them with POST /v1/sessions instead of calling this endpoint in a loop.

Two ways to address a dealer

dealership_id wins if you send both. A dealer_url whose host is already one of your active, configured dealers is treated as that dealer — you do not get a second, worse answer for a rooftop you have onboarded.

Query parameters

Outcomes

The source field is the answer to “did we get this from the dealer just now?”. Read it before you read the price. cached is never a price you should quote as current. It means the fetch failed, not that the car is unchanged.

cached_reason

gone_confirmed

On the un-onboarded path a gone carries gone_confirmed. A cached provider id that has gone stale looks identical to a sold car on several platforms, so before returning gone we ask the same ids, unfiltered, whether they can see any inventory. true means that check passed and the withdrawal is real. false means we could not complete the check — the listing is probably gone, but it is not confirmed.

Provenance fields

Two fields tell you where the numbers came from. They exist because a live fetch can succeed and still be missing something the stored row has.
breakdown_source: "none" is not cosmetic. On some platforms the dealer’s live API omits a documentation fee that the dealer’s own website displays, so a live-only price can be lower than the advertised price. Where we have a stored breakdown we carry it and report breakdown_source: "stored"; where we do not, the price may exclude dealer fees and breakdown_reason says so.

The vehicle object is shaped differently here

On this endpoint price_components and photo_url_list are returned as native JSON objects and arrays. On the feed endpoints — Get Vehicle by VIN, Search Vehicles — the same fields are returned as JSON strings that you have to parse.So JSON.parse(vehicle.price_components) works against the feed and throws against this endpoint. Check the type, or branch on which endpoint you called.
Every other field follows the vehicle schema, including fees_included_in_final and fee_total_from_components.

Latency by tier

tier is how the dealer’s platform has to be reached. It sets the deadline. Add roughly 300 ms–1 s the first time you ask about an un-onboarded dealer: their homepage has to be fetched and the platform identified. That result is cached per host for 7 days, so the second call is as fast as an onboarded one. fresh=true pays the cold cost every time, by design. The deadline is applied to the request itself, so a slow dealer costs you the deadline and no more.

Examples

Onboarded, source: live

fetch_ms: 94 is the dealer’s own response time; the rest of the 674 ms round trip is our gates and your network.

Un-onboarded, source: live

A dealer you have never onboarded, addressed by URL. Note dealership_id: null, the dealer block describing what we found, and breakdown_source: "none".
resolved is detected on a cold call and cached once the host is known. tunnel_used tells you whether the discovery fetch needed the unblocking tunnel.

source: gone

source: prewarmed

The same VIN immediately after a session warmed it. observed_at is when the warming fetch saw it, not when you asked — you are being told the age of the data.

Errors

The un-onboarded path is metered separately from this endpoint’s own class, because discovery costs us a homepage fetch on top of the VIN call.