Programmatic Data Feed for Car Auctions & Sites

No. TheCarApi is a data and inventory API. We expose normalized search, detail, images, catalog data, and market signals. Bidding and purchasing require your own credentials with each platform.

Send your API key via X-API-Key header or Authorization: Bearer <key>. Query-string api_key is optional and only if enabled server-side. Invalid keys return 401; repeated failures lock out the IP (5 fails / 5 min → 15 min lockout).

Always persist site_name + auction_id_str (e.g. auto1/48291033), preserving the id as a string. Numeric-only legacy IDs can collide across sources and return HTTP 409 on ambiguous endpoints.

Public inventory is 1M+ live vehicles across Auto1, OpenLane, Schadeautos, Copart DE, eCarsTrade, Encar, KB ChaChaCha and the Japanese auction houses. Full indexed history exceeds 5M vehicles with 500K+ archived for historical / delta products. The 9.8M European retail classifieds listings are counted separately — they are a market-reference dataset, not auction inventory.

It is 9.8M retail listings gathered from 681 classifieds portals, dealer sites and manufacturer stock pages across 39 European countries — asking prices, not auctions. Because those rows have no bidding, no auction end date, no detail payload and no gallery (one remote thumbnail per listing), they live in their own tables with their own vocabulary (seller type, origin portal). They are never merged into /api/search and never appear in /api/sites. Query them at /api/classifieds/listings, /api/classifieds/facets and /api/classifieds/models under the classifieds scope (theparking remains a legacy alias).

Yes. eCarsTrade behaves like every other auction source: it is a valid site value for /api/search, /api/auction/{site}/{id}, /api/car-details, and the import calculator site_name fee model. Detail payloads are full; the gallery arrives under the ImageUrls key of car_identification.

Use the vehicle_details block on /api/auction/{site}/{id} and /api/car-details. Each auction house names the same concepts differently — a downloadable file is Documents[] on Auto1 but ECarsTradeDocuments[] on eCarsTrade, while Documents on OpenLane is a dict of paperwork booleans and not a file list at all — so vehicle_details normalizes condition, documents, inspection reports, service history, equipment, warranty, specs and location into one shape. Coverage is not uniform: eCarsTrade has no per-panel damage list upstream, OpenLane publishes no document files, and only eCarsTrade has per-visit service rows. Normalized report URLs are served through /report-vault and cached; unsupported hosts or non-file pages can redirect upstream. Raw per-source data stays in car_identification.

Because those figures are quoted to our buyer account and our delivery address, not yours — OpenLane gates them behind per-account visibility flags, Auto1 prices routes from our merchant profile, eCarsTrade quotes to our warehouse. Publishing them next to a public price would also expose our markup by subtraction. Fee, bid-history, transport and delivery blocks are stripped at the response boundary, along with anything identifying our account on a platform. Still served: the auction house’s own published asking prices, VAT scheme, estimated repair cost, and the seller/warehouse location. For landed cost, use the import calculator, which prices your own route.

There are two kinds of price and it is worth knowing which one you hold. Every listing — spec, condition, availability and price — is refreshed by the scheduled ingestion pipeline; that is its cycle price, and for a fixed-price listing, a buy-now car or a lot that is not taking bids it is simply its price. The exception is a running auction with open bidding on openlane or ecarstrade: for those the bid is read from the auction house at the moment you request the car detail, and the response carries a live_price block. There is no separate real-time endpoint, no parameter to switch on and no premium tier for it. Search results, facets and top offers are never live-priced — they serve cycle prices, which is what makes them fast enough to page through. An absent live_price block is not an error; read live_prices from /api/contract to tell "live prices are unavailable" from "this car has none right now".

Yes, in two clearly separated fields. co2 is the measured figure the auction house published, present on roughly half of EU lots. co2_estimated is derived for lots that publish none, and is never a measured value — an estimate must not be able to masquerade as a measurement. Because EU registration documents switched from NEDC to WLTP on 1 January 2021 and the same car reads 12-25% higher under WLTP, every estimate ships with co2_estimated_standard telling you which cycle it is on. Estimates are EU-market sources only: Korean, Japanese and American lots are homologated on different cycles, so no EU figure exists for them.

No, and this is worth checking before you scope a feature. Auto1, OpenLane and eCarsTrade publish deep condition data; Schadeautos, Copart and Encar are moderate; the Japanese auction feed is shallow and its vehicle_details is often sparse or absent. Only eCarsTrade has per-visit service history rows. Only Auto1 has paint measurements and the DAT equipment catalogue. OpenLane publishes no document files at all, only paperwork booleans. The common core — identity, make/model/year, fuel, gearbox, mileage, prices, steering, images — is consistent everywhere. The Fields by source page in the documentation carries the full coverage matrix.

Yes. Search cards carry thumbnail_url, and the full ordered gallery arrives on the auction detail response as vault_gallery — the exact body GET /api/auction-images/{site}/{id} returns, so a detail page is one request rather than two. Each entry carries a URL that works right now: served_url once the photo is stored on our CDN, remote_url until then, plus image_status, dimensions and a pending count for photos still landing. Stored photos are AVIF or WebP depending on what the source served, so rely on the URL and content type rather than the extension, and use a client that follows redirects — /image-vault/* paths answer with a 302 to a pre-signed object URL.

Three layers. The common core — identity, make/model/year, fuel, gearbox, mileage, prices, steering, images — is identical across all eight sources and is what search cards carry. vehicle_details on the two detail endpoints is the normalized condition and paperwork block: same key names everywhere, presence varying by source. car_identification is the raw source-specific spec map, returned on auction detail as well; its keys follow each upstream own naming and change when the upstream changes, so prefer vehicle_details for anything you depend on long-term.

Yes. A managed key can carry fixed-window quotas on any of four periods — minute, hour, day and month — and the tightest configured window is reported as X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset. A key issued with no quota sends none of those headers: their absence means unlimited, not limit reached. A breach returns 429 with Retry-After; honour it rather than backing off on a schedule of your own. Windows are fixed rather than sliding, so a burst across a window boundary is expected. Five failed authentications from one IP trigger a 15-minute brute-force lockout, also a 429, including requests that then carry a valid key. Contact us for production quotas.

Use /api/archive/search, /api/archive/auction/{site}/{id}, and /api/archive/stats with an archive scope grant. Coverage and final-price availability vary by source; last observed prices are not confirmed sale prices.

Usually. Auto1 states no chassis number in its payload but photographs the registration certificate, so we read the VIN off that paperwork with OCR. Opening an Auto1 detail queues the car and the answer arrives on the next read as vin_ocr — { vin, confidence, evidence } — with vin_ocr_pending: true meanwhile, exactly like the live-price flag. A high-confidence read also fills chassis_number, so a client that only reads that field gets it without changing anything. About 41% of Auto1 cars with a document photo end up with a published VIN; the ceiling is upstream, because Auto1 blurs the VIN field on Spanish, Italian and Portuguese certificates. Only a confident read is presented as the car’s identity — a weaker one rides along labelled rather than silently asserting a VIN one OCR pass produced.

No. The same Korean car is often listed on both marketplaces at two different prices with two different photo sets, and ingesting both naively doubles your Korean inventory. We group the listings on VIN, or on a corroborated licence plate together with make and model — never on specification alone, because similar specs are not an identity. The duplicate is hidden from search and one representative card is published, with both asking prices still attached: source_comparison carries every offer for that car with its own price and link, which source was selected, the spread_eur between them, the match_method that grouped them, and the image_source the gallery came from. Photo sets are never interleaved. Korean source totals are therefore not the sum of the two upstream websites. The merge metadata is a separate field grant — ask for korea_merge if you want to show the comparison yourself.

Yes, by VIN. /api/vin/{vin} returns every auction appearance we hold for a full VIN across live and archived inventory — up to 100, newest first, deduplicated on (source, auction id) so one lot never appears twice. Each appearance carries its own mileage, price and lifecycle timestamps and is flagged live or archived, so a relist, a re-export or a mileage rollback is visible rather than inferred. A VIN that is not 17 valid characters is a 400; a valid VIN we have never seen answers 200 with match_count: 0. It is a sensitive route and is not enabled on a new key by default — ask for it.