Auto1 inventory data: what exists, what does not, and the options

Auto1 Group operates the largest pan-European wholesale vehicle marketplace. If you are building anything that needs a broad view of European used-car wholesale supply, its inventory is not optional — it is the reference set that everything else gets compared against.

Which is why "Auto1 API" is a common search, and why the result is usually disappointing. This article sets out what is actually available, why, and what the realistic paths are.

What Auto1 is, structurally

Auto1 is a closed B2B marketplace. Vehicles are sourced largely from consumers and fleets, inspected, and then offered to a network of registered professional buyers across Europe. The consequence for anyone wanting the data is that the marketplace is designed around verified dealer accounts, not around open access.

• Listings are aimed at professional buyers, with condition reports and inspection detail rather than consumer marketing copy.
• Access is tied to a registered trade account, typically requiring a verifiable business.
• Pricing conventions are wholesale: net figures, buyer fees layered on top, and margin-scheme VAT treatment that differs from retail.
• Stock turns over quickly — the lifespan of an individual lot is short, which makes freshness the dominant technical requirement.

Is there a public Auto1 API?

Not a general-purpose, self-serve, publicly documented one that a developer can sign up for and start calling. That is the state of affairs as far as public documentation goes, and it is consistent with the marketplace being closed by design.

There are two things that sometimes get mistaken for a public API and are worth naming so you do not waste a week on them. Internal endpoints that a logged-in web session calls are not a published interface: they are undocumented, unversioned, session-bound, and change without notice. Partner or integration APIs, where they exist, are commercial arrangements with contractual terms rather than something you self-serve.

Why the closed model makes technical sense

It is easy to read this as gatekeeping. The structural reasons are more mundane, and understanding them tells you what any access route will look like.

1. 1Wholesale pricing is commercially sensitive. Trade buy prices published openly would undermine both the sellers' position and the platform's.
2. 2The buyer network is the product. Verified dealers are what makes the marketplace liquid; open access dilutes the thing being sold.
3. 3Listing photography and condition reports are owned assets that the platform invests in producing.
4. 4Regulatory exposure. Fleet and consumer-sourced vehicles carry provenance data that the platform is accountable for.

The realistic routes to the data

Three, with genuinely different trade-offs.

1. Direct commercial arrangement with Auto1

If you are a large buyer or a strategic partner, this is the cleanest route — first-party data, first-party terms, no intermediary. It requires commercial standing and a procurement process, and it gets you exactly one source. For teams whose product needs a cross-platform view, that last point is the limitation.

2. Collect it yourself

Technically possible and legally and operationally non-trivial. Auto1's buyer-facing content sits behind authentication, which changes the character of the exercise significantly compared to scraping a public page — you are operating an account under its terms of service. The maintenance burden is covered in the cost breakdown; the additional consideration here is that access is tied to an account that can be withdrawn, which makes it a fragile foundation for a commercial product.

3. A multi-source data provider

The route that exists because of the gap between one and two. A provider maintains the source relationships and pipelines, and exposes Auto1 inventory alongside other platforms under one schema and one key. You trade first-party directness for coverage breadth and for not owning the maintenance.

What Auto1 data looks like normalized

On our side Auto1 is one of seven auction sources, reachable under the site slug auto1 and addressed by the same site/auction_id pair as everything else:

# Auto1 stock only, diesel, from 2018, cheapest first
curl -s "https://api.thecarapi.com/api/search?site=auto1&fuel=Diesel\
&year_from=2018&sort=price_low&limit=24" \
  -H "X-API-Key: $API_KEY"

# One lot, full normalized detail plus the raw source payload
curl -s "https://api.thecarapi.com/api/auction/auto1/1313664441" \
  -H "X-API-Key: $API_KEY"

# Gallery, re-hosted as WebP on CDN so it survives the lot closing
curl -s "https://api.thecarapi.com/api/auction-images/auto1/1313664441" \
  -H "X-API-Key: $API_KEY"

The point of the shared shape is that swapping site=auto1 for site=openlane changes the source and nothing else about your code. Cross-source comparison — the same model on Auto1 versus OpenLane versus Copart Germany — is the capability that no single-source route can give you.

Choosing between the three

A short decision rule that holds up in practice:

• You are a major buyer and Auto1 is effectively your only supply channel → go direct. Nothing beats first-party.
• You need one narrow slice — one brand, one country, low volume → a small in-house collector may be proportionate, with the account-dependency caveat understood.
• You are building a product — a marketplace, a pricing model, an exporter tool — that needs more than one source → a provider is almost always the right call, because the value is in the comparison and no single source can produce it.

For the equivalent picture on the other major European platform, see OpenLane auction data. For the full list of what we cover and how each source behaves, the sources page has the detail.