From inventory files to inventory events: the case for real-time vehicle inventory updates
A vehicle sells at 10 a.m. Most systems hear about it in tomorrow's file. Here's why inventory needs to move as events, one change at a time.

A vehicle sells at 10:15 a.m. The dealer's inventory system knows right away. The listing sites, ad catalogs and shopping assistants find out later, usually the next time someone sends them a file. Real-time vehicle inventory updates close that gap. Each change goes out when it happens, and every system showing the vehicle hears about it at once.
In this article
- How vehicle inventory moves today
- Why scheduled files fall behind
- What real-time vehicle inventory updates change
- Who feels the gap
- Where ÆTHR fits
- Key takeaways
Most dealers have lived that gap. A shopper calls about a truck that sold yesterday. An ad keeps spending on a unit that's gone. A price cut shows on the website and nowhere else until morning.
Nobody on the team caused it. It comes from how inventory moves between systems.
How vehicle inventory moves today
Most vehicle inventory still travels as files on a schedule. The pattern runs in six steps:
Generate → Export → Transfer → Import → Process → Discover change
An inventory system generates a file listing every vehicle. It exports the file and transfers it, often to an SFTP folder. The receiving system imports it, processes the whole thing and only then discovers what changed since the last one.
The large platforms are built around this pattern. Google's vehicle listings program asks partners to upload a full inventory file at least once a day and recommends every four hours. It doesn't accept partial updates, so every file has to hold every vehicle for every dealership (Google for Developers). Google's vehicle ads ask for data at least once a day as well. Sending it more than once a day takes a request to Google's support team (Google Merchant Center Help).
Daily files made sense when inventory changed slowly and a person looked at a listing before a shopper did. Neither holds today.
Why scheduled files fall behind
A file is a snapshot. It's right at the moment it's made, and it starts aging a minute later.
Inventory doesn't wait for the snapshot. Cox Automotive estimates U.S. dealers sold about 1.35 million used vehicles at retail in September 2026, from 2.21 million used units in stock (Cox Automotive). That works out to roughly 45,000 used sales on an average day, and every one is a change some system has to hear about. Prices move, photos arrive, incentives start and end and trims get corrected, all between uploads.
Each handoff adds its own wait. Google estimates about six hours for an added, removed or updated car to show up in vehicle listings, and says those times aren't guaranteed (Google for Developers). Put a few hours of export schedule in front of that, and a sold vehicle can stay live for hours after it leaves the lot.
Running the same export more often shortens the wait. The pattern stays the same. Every receiving system still reprocesses the whole inventory to find the one vehicle that changed. Each one finds it on its own clock. That's how the same vehicle ends up with different data in different places.
Your inventory changed 30 seconds ago. Does your ecosystem know?
What real-time vehicle inventory updates change
Real-time vehicle inventory updates put the change first. Systems act on it as it arrives:
Change → Stream → Act
A price drops. That one change, tied to that VIN, goes to every connected system when it happens. Nobody rebuilds a file, and nobody reprocesses 300 vehicles to find one. The ad catalog, the website and the partner app each get the same update and act on it.
Three things improve when inventory moves as events:
- Every system hears the same thing. The change goes out once, to everyone, so systems stop drifting apart between uploads.
- Sold vehicles come down sooner. A sold unit can leave every connected system without waiting for the next file. That means fewer calls about vehicles that are gone and less ad money spent on them.
- Partners can build on change itself. A tool that reacts when a price drops or a vehicle arrives needs to know when it happens. With files, it can only compare today's snapshot with yesterday's.
Speed has a catch. A wrong price that moves faster reaches more systems sooner. Every event has to be checked before it leaves, or streaming just spreads mistakes quicker.
Who feels the gap
Each part of the industry feels the lag in its own way.
- Dealers take calls about vehicles that already sold and see prices that disagree from site to site. (ÆTHR for dealers)
- Agencies pay for ads on units that are gone, and lose ads when the catalog and the landing page drift apart. (ÆTHR for agencies)
- Technology partners ship products that look wrong when the data under them is a day old. The dealer blames the product. (ÆTHR for technology partners)
- AI assistants answer shoppers from whatever record they can reach, as it stands. (ÆTHR for AI)
Where ÆTHR fits
ÆTHR is the trust layer for automotive inventory data. It works between your inventory sources and every system downstream, and it moves inventory as a stream of changes. For the full definition, read What is a trust layer for automotive inventory data?
Every change runs through four stages before it moves on:
- Validate checks the change against OEM build and incentive data and every other source describing the same vehicle, so a wrong price gets caught before it spreads.
- Standardize maps every source to one consistent record and delivers it in the format each receiving platform expects.
- Enrich fills gaps in the record from the vehicle's real data, including a description written for that VIN.
- Stream sends the change to every connected system as it happens, through one open API.
You can follow one vehicle through each stage in the ÆTHR engine.
Some destinations still only accept a scheduled file. ÆTHR delivers in the format each one expects, and it builds those files from records it has already checked.
Prism, part of ÆTHR, closes the loop. It looks at what's actually live on the dealer's website, separate from any feed, and pushes a fix back when something doesn't match.
You keep the systems you run today. The change is in how inventory moves between them.
Key takeaways
- Most vehicle inventory still moves as scheduled files, and major platforms such as Google ask for a full file at least once a day.
- Real-time vehicle inventory updates send each change to every connected system as it happens, so sold units and price changes stop lagging behind.
- ÆTHR checks every change before it streams, then Prism confirms what's live on the dealer website.
Next step
See what ÆTHR does for technology partners.
Sources
- Google for Developers, "Feed setup" (vehicle listings): https://developers.google.com/vehicle-listings/integration-process/feed-setup?hl=en
- Google Merchant Center Help, "Register and submit your data source": https://support.google.com/merchants/answer/11190110
- Cox Automotive, "Used-vehicle inventory, September 2026" (Oct. 16, 2026): https://www.coxautoinc.com/insights/used-vehicle-inventory-september-2026/