How does inventory reach a website you own?

A dealership that owns its website still has to show inventory, and inventory changes all day. Cars arrive, sell, get repriced and gain photos. This guide follows a vehicle from the dealer’s systems to a page on a site you own, and spends most of its time on the ways that journey fails. It is drawn from building and running inventory ingestion for a dealer group, described here without any provider’s file format or field names.

What information does an inventory feed need?

At minimum a feed must identify each vehicle and classify it: the vehicle identification number, new or used condition, model year, make and model. Without those five a record cannot become a useful page, and an importer should reject it with a reason rather than guess.

Everything else is optional but valuable: stock number, trim, body style, colours, odometer reading, transmission, drivetrain, fuel, engine, the date the unit arrived, prices, photo addresses, a description, options and features, and links to a detail page, a video or a history report. A good importer accepts the optional fields when present and renders the page gracefully when they are not.

Identity is more than a stock number

Stock numbers are assigned by each store, so two stores in the same group can use the same stock number for different cars. Treat the unit’s identity as the combination of store and vehicle identification number, and keep the stock number as a display and lookup field. Normalise the identification number on the way in — trimmed and uppercase — so the same car does not appear twice because of a stray space.

Keep internal financial fields private

A snapshot from a dealer system often carries fields that must never reach a public page: dealer cost, internal notes, days in inventory, wholesale values. The safest pattern is an allowlist. The importer copies only the fields the website is meant to show, and everything else is dropped before it is stored anywhere the website can read.

Prices deserve the same care. A feed may carry several: an asking price, a manufacturer’s suggested price, and a special price with an expiry date. Decide which one the page shows, show a special only while it is current, and never compute a public price from an internal field.

Where do vehicle photos come from?

Dealer systems frequently carry no photos at all. Photos usually come from a separate service that photographs the lot and publishes images on its own public host. In that case the feed carries photo addresses, and the website shows images directly from that host rather than copying them.

That is a reasonable arrangement: the photo host is already the vehicle-data source for images, and re-hosting them adds storage and staleness without adding trust. Show one lead photo in search results and a bounded gallery on the detail page, and give every image meaningful alternative text built from the vehicle’s year, make, model and trim.

How fresh is the inventory visitors see?

Feeds arrive on a schedule — sometimes once a day, sometimes every few hours — and the schedule differs by provider and by store. Freshness is therefore a property you have to measure, not one you can assume.

Track the last successful import, not just the last attempt

Record two timestamps per source: when the importer last ran and when it last applied a good file. Only the second tells you how old the inventory on the site is. A reasonable rule marks a source stale when its last good file is older than twice the expected cadence or a full day, whichever is longer, and failing when several consecutive runs have not succeeded. Show staff that status somewhere they will see it.

Polling more often than files arrive does no harm, and it shortens the gap between a file landing and the site showing it. On the system we run, a provider moved from one export a day to several, and the importer needed no change because it reads whatever is newest and applies it once.

Expect the first file from a new provider to take a while. Do not let monitoring alarm before a source has ever delivered; providers routinely need weeks to set up a new export.

What should happen when a feed is wrong or incomplete?

Every feed eventually sends something wrong. The goal is that a bad file never makes the site worse than it was a minute earlier.

Reject bad rows without losing good ones

Validate each row on its own. A row missing a required field, or carrying an impossible value, is rejected with a recorded reason, and the rest of the batch continues. One malformed vehicle should never block a hundred good ones.

Build the importer against a real file, not a description of one. On the system we run, a column map written from the expected header rejected every real file until it was rebuilt from an actual delivery.

Guard against accidental mass removals

A truncated or empty file looks exactly like a lot that sold out overnight. Before removing vehicles that are missing from a new file, compare the counts: if an unusually large share of the units would disappear, or the file is empty, skip the removal step and raise an alert instead. A person can confirm a genuine clearance in seconds; a site that blanked its inventory by mistake loses a day of shoppers.

Refuse older files and incomplete uploads

Files sometimes arrive out of order. Record the timestamp of the last applied file and refuse any file older than it. Uploads can also be read while they are still being written; wait until a file has been unchanged for a few minutes, and ignore files that still carry a temporary upload name.

Synthetic example. A fictional two-store group sends six units. Two stores both use stock number 1042; one unit has no price; an upload is interrupted halfway through. The sample below is illustrative only — the identification numbers are fake.

store,vin,condition,year,make,model,stock,price,photo_url
north,1FAKEVIN000000001,used,2021,Example,Sedan,1042,18995,https://photos.example.com/1.jpg
south,1FAKEVIN000000002,new,2026,Example,Wagon,1042,,https://photos.example.com/2.jpg
north,1FAKEVIN000000003,new,2026,Example,Pickup,1043,41250,
south,1FAKEVIN000000004,used,2019,Example,Coupe,2077,15400,https://photos.example.com/4.jpg
north,1FAKEVIN000000005,new,2026,Example,Sedan,1044,27900,https://photos.example.com/5.jpg
south,1FAKEVIN0000000

How should the site show unpriced, in-transit and sold vehicles?

Unpriced units are a real state, not an error. Show “Call for price” or omit the price line; never print zero. In-transit units often arrive looking available but with no arrival date, no detail page and few photos. Hide them unless the dealership wants them shown, and label them clearly as in transit when they are.

Sold vehicles leave two traces. Their detail pages start returning “not found”, which is correct, and those addresses show up in search reports for a while. Link from the not-found page back to inventory search so a late visitor has somewhere to go. If inventory lives behind a retail platform that blocks non-browser fetchers, remember that AI crawlers cannot read those pages either; your content pages are what they can see.

What should you ask for before building the integration?

Ask the provider for a real sample export with written permission to use it, the delivery method and schedule, how they mark deletions, how they send photos, and who to contact when a file stops arriving. Ask the dealership which fields are public, how unpriced and in-transit units should appear, and who receives stale-feed alerts.

Then agree how you will check the integration once it is live. A short routine works: compare the site’s unit count with the dealer system each morning for the first weeks, open a few detail pages at random, confirm that a car sold yesterday is gone, and read the importer’s rejected-row log. Most problems show up in that log before anyone notices them on the site.

Limits of this guide. It makes no claim about photo pixel sizes or formats; those depend on the photo service. Provider cadence varies by provider and by store, so the timing rules above are starting points to tune, not standards.

To start, bring an authorized sample export, a few example photo addresses and the cadence you expect, and we can map the import and its failure states together.