AutoInside API: Track Korean Used Car Listings Over Time

AutoInside as a data source

AutoInside lists used cars for sale with an asking price, which places it with the marketplaces in KoreaCarsAPI. Its records come back with is_auction=false and follow the same vehicle and listing fields as Encar, KB ChaChaCha and the other marketplaces.

KoreaCarsAPI is an independent data service and is not affiliated with AutoInside.

Why time matters more than a snapshot

A single export tells you what is for sale today. A series of exports tells you how fast cars sell, how prices move and which models are getting harder to find. That is the view most buyers and analysts actually need:

• Exporters who want to know whether a model is usually gone in days or sits for weeks.
• Pricing teams that watch how asking prices drift after a car is first listed.
• Dealers abroad who plan purchases around supply of a specific generation.
• Data teams that feed a market index or dashboard.

The time fields in every listing

Each listing carries three dates. created_at is when the listing first appeared. updated_at is when something on it changed. last_seen_at is the last time the listing was still active on AutoInside. Together they let you measure time on market without guessing.

Listings also keep a price history: each change is stored with its date. A car listed at one price, cut twice and then gone tells a very different story from one that disappeared at its first price. Odometer, photos and the source URL sit next to these dates, and the vehicle part adds year, brand, model, generation, trim, fuel, transmission and the rest of the specs.

Because AutoInside records share the same fields as every other marketplace, a monitor written for AutoInside works unchanged for any other source. That is a good reason to start small: build the pipeline on one source, check that your rules for new, changed and gone cars behave as you expect, then widen the domains[] list.

Counting the market with /search/count

For monitoring, counts are often more useful than full records. GET /search/count returns how many cars match a filter, so you can log the size of a segment every day and chart it. Add domains[] with AutoInside's ID from GET /domains to count its listings only. Use GET /search when you need the cars themselves, and GET /cars when you want the full AutoInside stock.

# Daily count of one model with 50,000 to 100,000 km
# BRAND_ID and MODEL_ID come from GET /brands and GET /models/{brand_id}
curl --get https://api.auctionsapi.com/search/count \
  -d "brands[0][id]=BRAND_ID" \
  -d "brands[0][models][0][id]=MODEL_ID" \
  -d odometer_from=50000 \
  -d odometer_to=100000 \
  -d api_key=$API_KEY

Practical tips for a market monitor

Monitoring is simple to start and easy to get subtly wrong. A few rules help.

• Store every price change, not only the latest price. The price history is already there, so keep it.
• Decide on a rule for when a car counts as gone, based on last_seen_at, and apply it the same way to all sources.
• Run your counts at the same time each day so the series is comparable.
• Keep the car_id as your key. It stays stable even when a listing changes.
• Separate marketplaces from auctions with is_auction, because asking prices and auction lot data do not mix.

Monitoring AutoInside with the other marketplaces

AutoInside on its own is one slice of the market. The same monitor run across Encar, KB ChaChaCha, K Car and the other marketplaces gives you a broader index, and because the record format is shared, adding a source is a matter of adding its entry in domains[].

If a VIN appears on several sites, GET /cars/vin/{vin} links the listings, which stops your monitor from counting the same car twice across sources.

Keep auction sources out of this kind of index, or in a separate one. Auction lots carry auction dates and lot data rather than asking prices, and mixing them into a retail index would blur both.

Questions