TheCarApi

The problem behind TheCarAPI sounds simple: let a developer search vehicle inventory from several sources through one interface.

The reality was much less tidy.

Auto1, OpenLane, Schadeautos, Copart Germany, eCarsTrade, Encar, and Japanese auction sources all describe vehicles differently. Makes and models need cleaning. Gearbox and fuel values need grouping. Condition reports have different shapes. Document fields do not mean the same thing. A numeric auction ID can collide with an ID from another source. Image URLs can disappear after a lot closes.

Then there is the market-context problem. Auction prices are wholesale signals, while classified prices are retail asking prices. They are useful together, but they should never be presented as the same kind of number.

We ended up building three connected layers:

1. A normalized auction inventory API with stable site_name + auction_id identity.

2. A durable image pipeline for vehicle galleries.

3. A separate European classifieds surface for retail-price context.

According to the live platform counters, the system now covers more than one million auction vehicles, over 50 million stored images, and 9.8 million European retail listings from 681 origin portals across 39 countries.

The most important product decision was not to force everything into one universal object.

Search uses a predictable common schema. Vehicle details add a normalized condition and paperwork layer. Raw source-specific fields remain available when the customer needs fidelity. Retail classifieds stay separate from auctions because their semantics are different.

We also learned that “API product” means much more than exposing JSON. Developers need pagination rules, rate-limit behaviour, stable identity, request tracing, contract versions, health endpoints, code examples, and a realistic explanation of missing fields. We now publish full documentation, an OpenAPI definition, a downloadable Postman collection, and a public Postman workspace.

The business model is intentionally simple: free temporary evaluation access, then one €250 monthly plan covering the full API surface for up to 200,000 requests. Custom exports and infrastructure are scoped separately.

The customers we think benefit most are:

● Vehicle marketplaces that need inventory before building direct seller supply

● Dealers and exporters comparing wholesale stock across sources

● Automotive data teams building pricing and market-intelligence products

● Salvage and parts businesses looking for damaged inventory

● ML teams working with labeled vehicle data and images

What we are trying to improve now is distribution and evaluation. The product exists, the documentation is public, and the technical content is live. The question is how to help the right teams discover it and understand quickly whether the coverage fits their workflow.

I would value candid feedback from other founders and developers:

● Which part would you evaluate first: source coverage, data quality, freshness, images, or pricing?

● What proof would you need before depending on an external vehicle-data provider?

● Would a working demo, sample export, or short integration call reduce the most uncertainty?

You can inspect the website, documentation, source coverage, and public Postman workspace.

I’m especially interested in speaking with people building automotive marketplaces, dealer software, export tools, or pricing products.