Ordered gallery for one listing
Image-vault gallery metadata. You usually do not need this call — /api/auction/{site_slug}/{auction_id} embeds the same body as vault_gallery. This endpoint stays supported and is the right one when you want the gallery on its own.
Every entry carries a URL that works right now: served_url once the vault has stored the photo, remote_url until then. Load served_url directly (same origin) and remote_url through an image proxy. Stored photos are AVIF or WebP depending on what the source served — rely on the URL and content type, not the extension.
pending is how many photos the auction still owes, so you can show placeholders instead of a silently short gallery. A non-zero pending also promotes the outstanding rows to user-requested priority, and both this and the detail response are served with max-age=10 until it reaches zero.
Returns {"success": true, "images": []} while nothing is stored yet.
Request
- Base URL: https://api.thecarapi.com
- URL: https://api.thecarapi.com/api/auction-images/{site_slug}/{auction_id}
- Auth: one of:
- API key in header X-API-Key
- HTTP bearer
- API key in query parameter api_key
Path parameters
Implemented inventory sources. /api/sites returns deployed sources and counts visible to your key. Japan has stored detail only. European classifieds use separate endpoints.
A source slug from /api/sites.
The integer database id of the auction.
Headers
Echo back the ETag from your last response for this URL. An unchanged page answers 304 Not Modified with no body. ETags are weak, so the tag stays valid whether or not the body came back compressed.
Response
The gallery.
Example response
{
"images": [
{
"source_section": "exterior"
}
]
}Changes
No recorded changes to this operation across all 1 revision of this API.