contract 2026-09-03
Data

Fields by source

What each of the eight inventory sources actually publishes — the condition-data coverage matrix, the source-specific traps, and how to write code that survives the differences.

Eight inventory sources feed one API, and they do not publish the same things. A German wholesale platform ships a full inspection report and a DAT equipment catalogue; a Japanese export lot ships an auction inspection sheet and a condition grade; Korean listings carry specifications and optional condition evidence. This page is the honest map of who gives you what, so you can decide what your product can promise before you build it.

Three layers of data

Every vehicle in the API is described at three levels of normalization. Knowing which layer a field lives on tells you immediately how portable it is.

LayerWhereConsistencyUse it for
The common coreSearch result cards and the top level of both detail endpointsIdentical across all eight sourcesListings, filters, sorting, price display, countdowns — anything that has to work uniformly.
The normalized detail blockvehicle_details on /api/auction/{site}/{id} and /api/car-detailsSame key names everywhere; presence varies by sourceCondition, damages, documents, service history, equipment. Check for the key, do not assume it.
The raw source mapcar_identificationSource-specific. Key names change with each upstreamThe last mile — a value the source publishes that has no cross-source equivalent yet.

The common core is guaranteed in the sense that the field is always in the contract; an individual value can still be null when a particular source does not publish it. fuel_group, for example, is empty for most Japanese lots — and a lot with no recorded fuel matches every fuel filter rather than none, so filtering by fuel never makes those lots unreachable.

What each source gives you

Read this table before you scope a feature. "Sparse" is not a bug to report — it is what the auction house publishes.

SourceWhat it isDepthWhat only it gives you
auto1Europe's largest digital B2B wholesale marketplaceDeep — full vehicle_detailsThe richest equipment data in the API (DAT catalogue), paint-thickness measurements, wheel condition, structured damages with a summary and prior-damage history.
openlanePan-European ex-lease and fleet auctionsDeep — full vehicle_detailsPer-damage free-text comments, typed report PDFs (internal damage, external damage, maintenance, battery health) and its own report index in car_reports.
ecarstradeBelgian online auction house — ex-lease, ex-rental, dealer tradeDeep — full vehicle_detailsThe only source with per-visit service history rows. Also the only source publishing estimated_value_eur, and the only one running blind auctions.
schadeautosNetherlands and Benelux salvage and repairable stockModerateSalvage-focused fields: engine capacity, transmission, VAT/margin status, net and gross export pricing, narrative damage text.
copartCopart Germany salvage and run-and-drive lotsModerateRun-and-drive signal, build-sheet series and special equipment, published lot prices; no at-request live-price overlay.
encarSouth Korea's dominant vehicle marketplaceModerate — deep specs, shallow conditionA large specification and options block, photo counts grouped by type, and registration data. Condition and accident detail is thinner than the EU sources.
kbchachachaSouth Korean cash-sale marketplaceSpecs and optional inspection evidencevehicle_details.kb_diagnosis / kb_inspection: status, report rows, checked controls, panel marks, images and VIN when present.
japanJapanese export inventory from 127 auction houses (USS, JU, TAA, CAA, ARAI, Honda and others)Shallow — expect vehicle_details sparse or absentImported photos, optional sheets and grades, originating sale information and matched reseller offer evidence. No on-demand detail fetcher.

Condition data: the coverage matrix

This is the table people actually need. It says which keys of vehicle_details you can expect from which source. Blank means the current integration does not promise that field. It may be unavailable upstream, not yet enriched, or omitted by permissions; absence is not a clean-condition verdict.

auto1openlaneecarstradeOther sources
damages (per panel)Structured, with summary, count and prior damagesStructured, with a comment per damageFree text + flags only — no per-panel list exists upstreamSparse or absent
inspection_reportsOne URLTyped PDFs by type_idAppraisal PDF + third-party linkKB uses kb_diagnosis / kb_inspection. Japan sheets are optional imported evidence.
documentsService book + service-detail imagesNone — paperwork booleans onlyService-history PDF + appraisal links—
service_historySummary onlySummary onlyPer-visit rows — the only source with them—
equipmentDAT catalogue (richest)Option list + accessoriesOption listVaries
paperworkPartialCOCAvailable, RegistrationDocsAvailable, IsV5Present, LicensePlatePartial—
estimated_repair_costsYesYesYes—

Source-specific notes worth knowing

eCarsTrade — blind auctions and the estimate

Most eCarsTrade auctions are blind: every bid is private, so no price is published anywhere and none is inferred. On such a lot current_price, start_price and buy_now_price are all null — and that is the correct, final answer, not a missing value to retry for. You do not have to infer it: the detail response carries is_blind: true, which is the one reliable way to tell "there will never be a price" from "there is no price right now". A client that renders "price unavailable, retrying…" without reading this flag retries forever.

What a blind lot often does carry is estimated_value_eur, the auction house's own valuation (its "eCT Estimation Price"). It is frequently the only number on the lot, which makes it tempting to render in a price slot. Do not. No bid is settled against it and no car is sold at it — a client that shows it as a price quotes customers a figure the auction will not honour. Label it explicitly as an estimate, and never sort or filter on it: it is null for every other source and on eCarsTrade lots without a published valuation, so any ordering that uses it silently drops them.

json
{
  "auction_id": 7479712,
  "site_name": "ecarstrade",
  "current_price": null,
  "start_price": null,
  "buy_now_price": null,
  "estimated_value_eur": 12000.0
}
A blind lot. Every price field is null and that is final — the estimate is not a substitute.

Japanese auctions — the price is an opening bid

A live Japanese lot has no hammer price until it closes, so current_price on japan is the opening bid, not a cost. Some lots publish no opener, and conflicting imported prices are withheld. Nominal starters can be far below the eventual price. Read it as a floor. buy_now_price is never set on this source, and best-value ranking will flag some of these lots optimistically as a result.

Japanese rows carry origin JP. Use country=JP or site=japan, and /api/auction/japan/{id} for stored details. /api/car-details does not accept Japan. Use the string id from search without converting it to a JavaScript number.

OpenLane — report types

OpenLane classifies each report it publishes. type is the readable name and type_id the source's raw code.

type_idtypeAppears in
1internal_damage_reportinspection_reports
2external_damage_reportinspection_reports
3maintenance_recordsinspection_reports
4option_reportoption_reports
5battery_health_reportinspection_reports
otherreportinspection_reports

Auto1's single inspection report is normalized into the same list with type inspection_report and no type_id. eCarsTrade's appraisal links arrive under documents rather than here, because the source itself presents them as documents.

Japanese auctions — the auction sheet

Japanese auction sheets and photos are optional imported evidence. Use the returned gallery and available report entries; the current importer does not promise a normalized auction_sheet entry on every lot, an extracted VIN, or live upstream detail fetching. The source specification and matched reseller evidence remain under car_identification; imported sheet URLs are under JapanMerged.AuctionSheetUrls.

Opening and downloading reports

Follow the exact returned /report-vault/{site}/{auction_id}/{token} URL; the token identifies an already-known report and is not an upstream URL you can construct. This delivery route currently needs no API key. A successful response is a binary file with its Content-Type, not a JSON envelope. download=1 requests an attachment. A 302 points to an upstream page; a 400 means an invalid token, a 404 means no matching report, and a 503 means the backing database is unavailable. Do not forward your API key to an upstream redirect target.

KB ChaChaCha — diagnosis and inspection

Read vehicle_details.kb_diagnosis and vehicle_details.kb_inspection independently: one report can be available while the other is unavailable. They preserve the source evidence rather than turning it into a universal accident score. Use the numeric carSeq for /api/car-details?site=kbchachacha&id=..., or the exact stored identifier from a search card for /api/auction/kbchachacha/{id}.

Report fieldShapeHow to use it
statusavailable or unavailableUnavailable means there is no usable report; it does not mean no damage. An absent block may also mean details have not been fetched.
rows{cells, cells_en}[]Ordered table rows with original and translated cells. Preserve row order and repeated labels rather than converting to a dictionary.
checked_controls{name, id, value, label}[]Selected controls on the source report. Keep the associated label; a raw checked value alone is not a diagnosis.
panel_marks{position, panel, code, condition}[]X replacement, C corrosion, W panel repair/welding, A scratch, U unevenness, T damage. Source position and diagram panel number differ. Some marks instead carry element_id and condition_original from the source diagram.
images / documentsarraysOptional visual evidence and document records. Use returned URLs; these nested links are not uniformly rewritten through the report vault.
vinstring or nullPresent only when a valid VIN is extracted. Missing VIN is not evidence that two listings are different vehicles.

Naming collisions to be aware of

The same word means different things upstream, which is precisely why the normalized block exists. A downloadable file is Documents[] on Auto1 but ECarsTradeDocuments[] on eCarsTrade — while Documents on OpenLane is a dictionary of paperwork booleans and not a file list at all. If you read car_identification directly, you own that problem. If you read vehicle_details.documents, you do not.

Steering side

steering is normalized to left or right. Explicit source evidence is used where supported; otherwise it is inferred from registration market. It is an inferred field where no explicit source value exists, not a universal physical inspection guarantee. Japanese imports may include left-hand-drive vehicles, so do not derive steering from country in your client.

Because every listing resolves to one side or the other, the two values partition the inventory: their counts sum to the unfiltered total. As a filter it takes two values, each with four equivalent spellings — left, lhd, left-hand, left_hand and right, rhd, right-hand, right_hand — and anything else is a 400. It is accepted by /api/search, /api/top-offers, /api/listVehicles and every facet endpoint — though on a facet endpoint it is computed live rather than read from the precomputed table, so it is slower than an unfiltered facet call.

Writing code that survives the differences

javascript
// Right: ask for the key, accept its absence, never branch on the source.
function conditionSummary(auction) {
  const d = auction.vehicle_details ?? {};

  return {
    // Present on auto1 and openlane; free text on ecarstrade; absent elsewhere.
    damages: d.damages ?? [],
    damageNotes: d.damage_comment ?? d.technical_issues ?? null,

    // ecarstrade is the only source with per-visit rows. Everyone else has a summary.
    serviceVisits: d.service_history ?? null,
    serviceSummary: d.service_history_summary ?? null,

    // Most listings carry no reports at all. Empty is normal, not an error.
    reports: d.inspection_reports ?? [],

    repairCost: d.estimated_repair_costs ?? null,
  };
}

// Wrong: this breaks the day a source is added, and hides data today.
if (auction.site_name === "auto1") { /* ... */ }
A missing key can mean unavailable evidence, pending enrichment or a field permission; do not interpret it as a negative finding.
  • Never hardcode the source list. Read it from /api/sites at startup. An unknown slug is a 400 naming the offender, so a stale hardcoded list turns a new source into a broken deploy.
  • Design for the shallowest source you serve. No source guarantees full service history on every car. eCarsTrade can provide per-visit rows where available. Promise it where it exists and degrade gracefully where it does not.
  • Treat car_identification as unversioned. Its keys follow each upstream's own naming and change when the upstream changes. Anything you depend on long-term should come from the common core or vehicle_details.
  • details_pending: true is not an error. It means the detail payload has not been assembled yet. Poll rather than retrying in a tight loop, and render the card data you already have.