There is no public coches.net API for listing data. What the site does publish is more useful than most people expect from a target with no API: a server-rendered payload and an unusually specific set of crawl rules. Between them they define exactly what a compliant integration can read.
The short answer
No public API, no key to request, no documented field contract and no rate-limit SLA. Anything that reads coches.net listing data — including this project's Actor — is reading the same pages a visitor's browser receives.
That is worth saying plainly because the alternative framing (“undocumented API”) is misleading. An internal endpoint you found is not an API; it is an implementation detail with no promise attached to it.
robots.txt as the closest thing to a contract
Where there is no API, the site's robots.txt is the only machine-readable statement it makes about automated access — and coches.net's is specific enough to build against. It allows the search and dealer sections, disallows detail-page patterns and internal endpoints, and enumerates disallowed pagination values individually from pg=7 to pg=69.
Read as a specification rather than an obstacle, that tells you three things: search pages are the intended surface, detail pages are not, and six pages is the permitted depth. Every one of those is a design decision you would otherwise have to guess at.
The server-rendered payload
Coches.net sends fully populated HTML with the listing data embedded, so one request returns 35 complete records. For a scraper this is the difference between an HTTP client and a browser farm.
It is also more stable than a JavaScript-driven front end would be. There is no hydration timing to race, and the payload shape changes far less often than the visual markup around it. That is why the Actor documents 55 fields with measured fill rates rather than a best-effort selection of CSS selectors.
What that means for your pipeline
- No versioning. Nothing guarantees a field will exist next month. Assert on the fields you depend on and fail loudly rather than writing nulls into a warehouse.
- No rate limits published, which is not permission to hammer it. The Actor keeps concurrency modest and paginates within the allowed depth.
- No pagination beyond six. Design for breadth from the start; retrofitting facet expansion onto a paginating crawler is a rewrite.
- No delivery guarantee. If the public data becomes unreachable without fingerprint spoofing, the correct behaviour is a reported failure, not a workaround.
Freshness without an API
With no feed and no webhooks, currency is your problem — so it has to be visible in the data. Every row from this Actor carries from_cache, fetched_at, scraped_at and data_age_hours, and maxCacheAgeDays: 0 forces a fresh read of everything.
Two timestamps rather than one, because “when your run produced this row” and “when this data came off coches.net” are different questions and only the second one tells you whether the price is current.
Alternatives worth knowing about
If your requirement is a contractual feed rather than scraped rows, the routes are commercial data licensing from the marketplace group or an automotive data vendor. Both are real options and both are priced accordingly; neither is available by signing up on a page.
For most analytical work — depreciation curves, regional price gaps, badge composition, below-market screens — the public surface is sufficient, and the Actor documentation lists exactly what it yields and how often each field is populated.
