Questions, answered

Everything we get asked about coverage, image options, integration, licensing and pricing. If yours is not here, one message gets you a real reply.

Getting started

What the API is and how you get the first image out of it.

It turns a vehicle description into a photograph-quality studio image. You send a make, model, year, variant and trim, or a VIN or licence plate, and get back a signed image URL you can put straight into an img tag. No photo shoot, no stock library, no retouching step.
An API key in an x-api-key header, and nothing else. The whole catalogue is a URL path, so you can explore it with curl before you write any code. The docs start with a working request.
GET /api/search?q=vw+golf matches free text against every brand and model, and forgives nicknames, misspellings and odd spacing. It answers with catalogue paths you can walk further. Put a year in the query and it will not match, years come one level deeper.
Yes. The examples page is a live demo marketplace: every image there is fetched from the API while you browse, and you can switch angles, repaint the car and change the background yourself. If you want it on your own vehicles, send us a few and we come back with the images, usually the same working day.
There is a package on npm and an MCP server for AI agents. Neither is required. It is an HTTPS endpoint that returns an image URL, which every platform already knows how to handle.
Most teams have an image on a page the same day they get a key, because the integration is a URL. Going from there to production is usually a question of where you cache, not of how much code you write.

Coverage

Which vehicles exist in the catalogue, and what happens when one does not.

100 brands and more than 65,000 models, current and past model years. GET /api/brands returns the live list for your key at any time, so you never have to trust a number on a marketing page. See the coverage page.
Past generations are covered, which matters more than people expect: used listings, remarketing catalogues and buyer guides are mostly about cars that left showrooms years ago. GET /api/{brand}/{model} lists every model year available for that model.
No. Vans, commercial vehicles, pickups and motorcycles render in the same studio look, so a mixed fleet page still reads as one catalogue. The examples page has a motorcycle in the grid for exactly that reason.
The API says so instead of guessing, so you get one branch in your code rather than a wrong car on a page. Where a requested model year does not exist it snaps to the nearest available generation and reports that in errornotes.
Continuously, as manufacturer data becomes available. For leasing and configurators that is the important part: a model usually exists in the catalogue months before the first one is built, which is when the offer page needs it.
Yes, GET /api/getall dumps every configuration available to your key in one response. It is large by design and meant for a nightly sync, not for a page load. See the endpoint.
Yes, keys can be scoped, and GET /api/me reports any restrictions under blocked_brands and year_range. Useful when a franchise agreement only covers part of the market.

Images and options

Angles, paint, backgrounds, formats and sizes. Everything is a query parameter.

Nine views: eight exterior angles (front, rear, both sides and the four three-quarter views) plus interior shots such as the centre console where the vehicle has them. Every one is a separate request on the same configuration, in identical studio framing. See all of them.
Yes, and the change repaints the actual studio shot, so a metallic still reads as metallic. Five house colours are available on every vehicle, each brand’s own catalogue paints come on top, and there are 3M wrap finishes as well. GET /api/{...}/colors lists what a specific car offers. See the colours.
Four options, each a single parameter: shadow=true for a studio drop shadow, ground=true for a contact shadow so the car sits on a surface, mirroring=true for a reflective showroom floor, and transparency=true for a clean cut-out you can place on anything. See the difference.
PNG, WebP, JPEG and AVIF, at widths of 200, 400, 800, 1200, 1600 or 2000 pixels, with quality between 40 and 100 (82 by default). There are also named presets from thumb (320px) to full (2000px) if you would rather not pick numbers.
Natively 3:2. Ask for another ratio and the image is padded rather than cropped, so nothing is ever cut off the car: 1:1, 4:3, 16:9, 16:10, 2:1, 21:9 and the portrait equivalents are all available. That is why a square grid card and a widescreen banner can use the same vehicle without a designer in between.
Yes, transparency=true returns a cut-out with a real alpha channel. Worth knowing: transparency forces PNG, and a PNG is several times heavier than the same car as WebP. Use it where you actually need the alpha, and WebP everywhere else.
Not on a normal plan. GET /api/me tells you exactly what your key allows, including whether a watermark is forced.
That is the point of rendering rather than collecting. Every vehicle uses the same camera position, distance and light, so a mixed table compares cars instead of comparing photographers. It is the reason fleet and leasing teams tend to arrive here.

Integration

How this fits into a listing page, an app or a document pipeline.

It is a path: /api/{brand}/{model}/{year}/{variant}/{trim}/{view}. A GET on any shorter prefix lists the next level down, so the entire tree is discoverable by walking it. No schema to learn before the first request.
Yes. A VIN works everywhere; plate lookup depends on the market. Make, model, year and trim resolve too, which is often all a listing form or a grey fleet declaration actually holds. More on lookups.
Every configuration has a permanent id. GET /api/id/{id} returns every available view, GET /api/id/{id}/{view} a single one. Ids survive catalogue updates and renames, so they are safe to write into your own database.
Yes, and most integrations do. Copy the image into your own storage and serve it from there, so a page load never depends on a call to us. Signed URLs stay valid for seven days, which is plenty of time to fetch and store.
It falls back to the closest valid value and tells you what it did in errornotes, rather than failing. There are 17 codes, each with a plain-English meaning, so you can log or ignore them deliberately. See the codes.
Usually far fewer than it looks. Identical configurations resolve to the same render, so forty of the same defleeted van is one image reused. Cache on your side and a screen showing the same twenty vehicles to every visitor costs twenty requests in total, not twenty per visitor.
It is a plain HTTPS URL, so your existing image loader and its disk cache handle it unchanged, on native and in a web view alike. Ask for the width the layout actually uses instead of downscaling a print asset on the device. More for app teams.
No, and deliberately so: the catalogue is pull-based. Sync it when you want with GET /api/getall, or read the changelog for what has shipped. Nothing needs an endpoint on your side.

Speed and reliability

What happens under load, and how you can check rather than trust.

They are served from a global edge cache, so the first byte comes from a location near the visitor rather than from an origin. A variant is generated once and served from cache after that.
Yes. The status page shows live uptime and response times measured from outside our own infrastructure. GET /api/status is a machine-readable liveness check for your own monitoring.
Cached variants do not reach the API at all, which is the normal case for a catalogue page where every visitor sees the same vehicles. That is also why a launch or a campaign day behaves the same as a Tuesday.
Nothing, if you followed the usual pattern: copy the image into your own storage once and serve it from there. Your page then depends on your own CDN, not on ours. That is the single most useful thing to build early.

Licensing and data

Where the images come from, and what you may do with them.

They are rendered from vehicle data we license. They are not photographs, and they are not scraped from dealer sites or press packs. That is the reason we can put the permitted uses in writing, which is usually the question that starts the conversation with a legal team.
Yes. Listings, apps, campaigns, print and customer documents are covered, with no credit line and no watermark. Tell us the document set you produce and it goes into the licence explicitly.
Yes, and for insurers and lenders that is normally the point: quotes, policy schedules, agreements and claim correspondence. See insurance and finance for how that is usually set up.
No. There is nobody in the picture and no location, which removes an entire category of clearance work that photography brings with it.
Vehicle identifiers, nothing else. A VIN can be sent without the policy, order or customer it belongs to, so nothing about a person needs to leave your systems.
It shows the model, trim and factory colour on record, which is how manufacturer imagery has always been used. It is not a photograph of one specific unit and should not be labelled as one. Most platforms present it as a representative image of that configuration and keep real photos as the gallery.
Displaying them to your users is covered by default. Letting users download or redistribute the files is a different right, so tell us if you need it and it goes into the licence explicitly rather than being left ambiguous.

Pricing and account

How this is priced, and what to send us to get a number.

By distinct configurations rather than by page views, which is why the cost curve flattens exactly where volume lives: a model you list a thousand times is not a thousand renders. See the plans.
A rough model mix and how many vehicles you list or serve per month. That is enough. For a rental operator it is the class list, for a lender the derivative mix, for a portal the monthly listing count.
No. A broker running a handful of proposals a week and a portal running millions of listings get the same images and the same options.
GET /api/me answers it in one call: enabled features, allowed formats, resolutions, ratios, views, colours and brands, plus any restrictions and the signed-URL lifetime. See the endpoint.
No. A configuration is rendered once; every later request for the same combination is served from cache. That is why a portal listing the same model a thousand times does not pay a thousand times.

Support and requests

How to reach a person, and what to do when you need something the API does not have yet.

Write to us or book a short call. Replies usually land the same working day, and they come from the people who build this rather than from a ticket queue.
Send us the make, model and year. Adding a model is normal work for us rather than a favour, and it is often the fastest way to find out whether a gap is a data problem or a naming mismatch.
Ask. A specific angle, a background treatment or a delivery format that is not in the list is worth a conversation; some of what is standard today started as one customer asking for it.

Nothing matches that. It might be a question nobody has asked us yet.

Ask us directly

Still stuck on something?

Tell us what you are building and we will answer with the specifics, usually the same working day.