React teams meet two problems on the same afternoon: the API key must never reach the browser, and a grid of vehicles must not jump while it loads. Resolve where your secrets live, ship URLs to the client, and both problems stop existing.
A fetch from a client component hands your key to anyone who opens devtools. Resolve vehicles in a route handler, a server component or your own backend, and the browser only ever sees finished image URLs.
Resolve once, pass URLs down, let the browser cache. Nothing clever happens here, and that is the point.
npm i vehicleimagery, then create the client where your secrets already live, not inside a component.
A VIN, a number plate or make, model and year go in. Image URLs for every angle come back.
Your card takes a string. No provider, no context, no client side fetching, no loading waterfall.
A fixed ratio wrapper plus a width parameter that matches the rendered size removes layout shift before it can happen.
Bring vehicle imagery into your product without the heavy lifting. Clear docs, open SDKs and ready-made plugins connect to your stack in minutes, and our status page shows you live how the API is doing.
Layout shift in a vehicle grid is nearly always an unsized image. Request the width the card actually renders, wrap it in a fixed ratio box, and the grid settles on first paint instead of settling twice.
Most React codebases start with a placeholder image and a promise to fix it later. The fix usually arrives as a client side fetch inside a card component, which is where the trouble begins: the key is exposed, every card opens its own request, and the grid reflows as answers arrive at different times. The API is fast, but the pattern is wrong.
The version that holds up is unglamorous. Resolve vehicles wherever you already load listing data, keep the resulting URLs on the listing object, and let cards render an img tag with a width that matches their layout. The browser caches by URL, the CDN handles the rest, and your component tree stops knowing that an image API exists at all.
You can, but you should not. A client component runs in the browser, so the key travels with it. Resolve in a route handler, a server component or your backend and pass URLs down as props.
Yes, and it is the cleanest fit. Resolve inside the server component that loads the listing, then render the URL directly. Nothing about the integration reaches the client bundle.
No, and deliberately so. The npm package is framework agnostic and returns URLs. A vehicle image is an img tag, and wrapping that in a component we control would only get in the way of your design system.
Give the image a fixed aspect ratio container and request the width you render. Because framing is identical across vehicles, one ratio works for the whole grid.
A neutral placeholder at the same aspect ratio. Since the URL is known before render, images usually load without a visible placeholder step.
Yes. The URLs are ordinary HTTPS image URLs, so the Image component consumes them directly. Resolve on your backend, exactly as you would for the web.
Tell us what your listing data looks like and which sizes your cards use. We come back with image URLs ready to drop into your components.
