Sector · Motor trade
Inventory in the motor trade is not a catalogue, it is a flow: vehicles arrive, are transferred between locations and leave again — and each vehicle is a one-off item with its own history and its own mandatory data. We have been working in this market for years: the same in-house TYPO3 vehicle search at three motor dealers, from a three-digit commercial vehicle inventory to more than two thousand passenger cars across six locations, plus our own inventory management system and a CRM under development. We are a mobile.de partner and work with their interface, and we are getting to grips with Google Vehicle Ads — we have not delivered that format in any client project, and we would rather say so up front.
There is no article number, no second unit, no restocking. Every vehicle needs its own data record with its own address, its own image series and its own history — and a clean removal once it is sold. Data models built for trade in series products do not fit here.
Internally, a multi-brand dealership is organised by location and by franchised brand; the prospective buyer is looking for an estate car with an automatic gearbox. The search has to show the complete inventory across all locations and treat the location as a filter, not as an entry point — at Autohaus Brüggemann that means 2,151 vehicles from six locations in one list.
The Pkw-EnVKV requires figures for fuel consumption, CO2 emissions and CO2 class on every passenger car that is advertised. Whether a particular vehicle is covered, and in which form, is a legal question and not a technical one. Technically, one thing applies in every case: these values must come from the source and must not be lost in any import. We therefore treat them as mandatory fields with validation: incomplete means an error list, not a live listing.
It often starts in the evening on a phone and continues days later at a desk, sometimes with a second person in the household. This is why filter states belong in the address and not in the session store — a result list that can be sent, saved and found again.
Anyone coming from trade in series products thinks in article numbers: one product, many identical units, a stock level as a number. That does not apply in the motor trade. Every vehicle is a one-off item with its own chassis number, its own mileage, its own combination of equipment and its own past. There is no second unit of the same article, and there is no restocking — once the vehicle is sold, the page is dead. Technically this means that every vehicle needs its own data record with its own address, and that its removal has to be handled just as carefully as its arrival.
The inventory moves every day. Vehicles come in from trade-ins, from procurement, from returned lease contracts and from factory orders; they are transferred between locations when a prospective buyer in Rostock asks about a car that is standing in Dortmund; they leave, often without anyone in the sales conversation thinking about the website. A system that reflects this flow only once a day as a full import produces two kinds of error: vehicles that are online and no longer there, and vehicles that are there and that nobody finds. The first kind leads to an awkward phone call, the second costs enquiries that are never made — and nobody sees it.
On top of that, search behaviour does not match the way the dealer is organised. Internally, a multi-brand dealership is divided by location and by franchised brand, because contracts, workshop capacity and responsibilities are cut that way. The prospective buyer is not looking for any of that. He is looking for an estate car with an automatic gearbox in a certain price range, and he is willing to drive two hundred kilometres for the right car. The website therefore has to show one inventory across all locations and offer the location as a filter instead of as an entry point. At Autohaus Brüggemann that means six locations — Rheine-Mesum as head office, plus Brandenburg, Dortmund, Neubrandenburg, Rostock and Wietmarschen — with 2,151 vehicles in one search and 24 brands in the filter.
And the research breaks up into separate sessions. It starts in the evening on a phone, continues the next day at a desk, and is occasionally handed on to a second person. That is the practical reason why filter states have to be in the address and not only in the session store: only then can a result list be sent, saved as a bookmark and found again. If you add this later, you pay for it twice.
We are a mobile.de partner and we work with the interface. The platform does not provide one API but five, with clearly separated tasks. The Seller-API handles inventory maintenance: creating, changing and deleting listings, uploading, assigning and reordering images, booking paid additional features, price assessment and statistics, leasing rates and direct offers, auto-panorama images, dealer ratings and your own contact persons. The Search-API — also listed as Ad-Integration — works in the other direction and searches for or retrieves listings. The Ad-Stream delivers events on the server side over WebSocket, the Insights-API delivers analysis of the listings, and the Lead-API gives access to leads. All five are XML-based.
Which of them is open to you depends on your account, and projects regularly fail at this point before the technical work even starts. The Seller-API requires an API-Account; activation and access data go through mobile.de customer service. For access to your own inventory through the Search-API, a Dealer-Account is enough: the dealer activates the Listing Integration in the dealer account and generates an API user name and password there. For registered dealers, this access to their own inventory is usually included in the monthly fee. This is not a minor detail but the first question we ask: it decides which route is open at all — and the activation sits with mobile.de, not with us and not with you.
The practical gain is simple and large: maintain data once instead of typing it three times. Without an interface, a vehicle is entered in the portal, entered on the company's own website and entered in the ERP system — three times, by three people, with three results that drift apart after two weeks. With an interface there is one source and channels derived from it. Before that, however, a decision has to be made that no tool can make for you: which system is the leading one, for each type of data. If the portal leads, the website is a copy of it. If your own system leads, the portal is an output channel. Both variants work, but not at the same time for the same fields.
The limits deserve plain words. The documentation rules out parallel requests for the same listing — if you update data and images at the same time, you have to serialise that. The maximum number of images per listing depends on the account, not on the technology. There are no published rate limits; for questions about volume, the documentation refers to support. For the implementation this means: a queue instead of a burst of parallel calls, a restart that continues where it stopped instead of starting again from the beginning, and a log that shows which data record was transferred at which time and in which state. Anyone who builds a portal connection without these three things has not built it, only started it.
We are a mobile.de partner and work with their interface. Alongside that, we are getting to grips with Google Vehicle Ads. This is an ad format that shows individual vehicles from commercial dealers directly in Google search results: image, make, model, price, mileage and dealer name. The click does not lead to a portal but to the vehicle detail page on the dealer own website. That is the strategic difference from a portal listing — and it is exactly why success depends on the quality of your own inventory online.
On the status in Germany you need to know that Google contradicts itself. The announcement of 27 March 2026 states that vehicle ads are available to all vehicle advertisers in Spain, Italy and Germany starting March 2026, and names Performance Max as the campaign type. The general overview page, by contrast, still lists Germany as an open beta requiring a contact form and approval, and additionally names standard Shopping campaigns. We treat the dated, explicitly Germany-specific announcement as the more recent source and the overview page as not updated on this point — but we check the current state before any commitment rather than relying on a snapshot. Before that, the format was generally available in Australia, Canada, Japan and the USA.
Technically Google requires four things: a Google Ads account linked to a Merchant Center account, a link to the Business Profile or, alternatively, a stored business data source, a vehicle feed in Merchant Center with all required attributes, and a campaign in Google Ads. The feed is the part that decides success or failure in practice: it has to be complete, current and machine-clean. Mileage is a required attribute and needs its unit; the vehicle identification number is optional in Germany. Anyone already publishing their inventory from an authoritative system to the website and the portal has done the groundwork — the feed is then one more output channel of the same source, not a third data store.
Part of the requirements concerns not the feed but your own vehicle detail page. Dealer name, location, price, the manufacturer recommended price for new vehicles, mileage for used vehicles and availability must be visible there, and the price in the data source must match the price on the page exactly. Anyone who shows delivery costs sometimes and hides them other times, or shows mileage only in the result list, will collect rejections. That is work on the template and on the data model, and it comes before a campaign makes any sense at all. On the seller side: only direct sellers may take part, intermediaries expressly may not.
On the question of which vehicles are eligible, we separate what is documented from what is open. Documented, and stable across both Google sources, is the exclusion: commercial vehicles, agricultural vehicles, buses, motorcycles, boats, aircraft and comparable categories are not permitted, nor is any vehicle requiring a commercial driving licence. A dealer in used articulated trucks therefore falls outside, and that genuinely applies in our own client base. What is not settled is the motorhome case: the policy page names motorhomes, campers and non-motorised trailers as permitted, but Google own announcement limits precisely that expansion to the United States from May 2026. For a German motorhome dealer the question is therefore open — we claim it in neither direction and settle it with Google before making any commitment. This is why Vehicle Ads is not a finished service with us: we prepare the data side, and we have not delivered the format in any client project.
The vehicle search on the websites of Autohaus Brüggemann, Nord Automobile and Eschen Nutzfahrzeuge is not a bought-in plugin but our own TYPO3 extension. What is interesting about it is the range: at Eschen it runs 152 used commercial vehicles, at Nord Automobile in Rastede 1,058 offers, and at Brüggemann 2,151 passenger cars with 24 brands in the filter. The figures are a snapshot from the live websites and move with the inventory; the orders of magnitude stay the same. The same data model, the same filter logic, three very different inventories — from heavy commercial vehicles in the export business to a multi-brand used car inventory.
This has one consequence that matters for a new client: every further development benefits all installations. An additional filter criterion, an improvement to the result list, an adjustment to changed mandatory data is built once and is then available everywhere. Conversely, we have seen the mistakes a vehicle search can make across three inventories and not just one. At Nord Automobile the search filters through a dedicated AJAX endpoint at /fahrzeugsuche/ajaxliste: price range, brand, model, first registration, mileage and sorting are evaluated on the server, and only the result list is reloaded. The page stays where it is and the result count updates with it. On a phone, that is the difference between an application and a form.
Filter states are in the address — search[make][], search[model][], search[garage][]. That sounds like a technical detail and it is a sales tool. A result list can be linked to: the salesperson sends the prospective buyer the filtered selection by email, an advertisement can point to a fixed selection with a QR code — for example all estate cars in a price range at the Rostock location — and a campaign lands on a selection instead of on the home page. Result lists can therefore be used in campaigns without building a separate page for every activity.
At Eschen Nutzfahrzeuge a further dimension comes in, one that is rare in the passenger car trade and normal in the commercial vehicle trade: export. The website runs in five languages — German, English, Russian, Polish, Spanish — from a single data entry. Technical details such as first registration, mileage, engine specification or axle configuration are language-neutral and need no second round of maintenance; what gets translated is what is genuinely text. All of it is fed by etruck, a system we developed ourselves, which runs there as the leading system for inventory, images and documents: PHP 8, MariaDB, Redis, in containers on our own servers in Germany, with no public access. Eschen also runs a separate extension for Google reviews. That is the evidence that in this field we do not improvise but have worked on the same core over many years.
In this sector, legal requirements depend unusually directly on data quality. The Pkw-EnVKV requires figures for fuel consumption, CO2 emissions and CO2 class on every passenger car that is advertised. This is not a footnote in the imprint but a mandatory field on the individual data record — in the result list, on the detail page, on the notice in the showroom, in the printed vehicle data sheet. Anyone with a four-digit inventory has a correspondingly large number of places where these figures have to be correct, and they are not held in the website but in the source. Which vehicles are covered in an individual case, and in which form the figures have to be given, is not decided by the technology — that is a legal question. The technology only decides whether the figures reach the listing at all.
This creates a hard requirement for the whole chain. The values have to come from the leading system and must not be lost on the way. An import that treats fuel consumption and CO2 class as optional fields and quietly lets empty values through moves a legal risk into a log file that nobody reads. We therefore treat such fields as mandatory fields with validation before writing: a vehicle without complete mandatory data does not go online but into an error list that names the data record. That is inconvenient in daily work, and that is exactly why it is right — the alternative is an advertised vehicle that may not be advertised in that form.
The second point where data maintenance means more work in this sector than elsewhere is images. A vehicle is sold through images and not through equipment lists. The image series is therefore the most demanding part of the data record: order, assignment, formats, images delivered later from vehicle preparation, replacing placeholders after the photo session. The Seller-API can upload, assign and reorder images — the implementation has to make sure that an image delivered later does not rewrite the whole series, and that a vehicle without an image is recognisable as such instead of going online with a grey box. Such cases are decided once in the concept or permanently in support.
Here we should state the position honestly: we are working on this, we are not selling a finished product. What exists is the foundation without which every conversation about AI in the motor trade stays a demonstration and never becomes a process. At Autohaus Brüggemann we are developing a CRM on a CCM2 basis in which customer, company, vehicle and case are separate objects with defined relationships — because in this sector customer and vehicle belong together over years: purchase, service, trade-in, follow-up purchase. Enquiries from the TYPO3 website, accounts and cases from the Shopware 6 trading platform and the data entered by the sales team all run into the same database. The project is under development, step by step, with no single switch-over date: data model and import first, then the working interfaces for the individual departments.
The starting points we see all lie behind the sale. Generating vehicle descriptions from equipment lists, so that two thousand vehicles do not carry the same paragraph. Pre-qualifying incoming enquiries and assigning them to the right salesperson — by brand, by location, by commercial vehicle or passenger car, by business or private customer. Prioritising follow-up tasks in the CRM, because otherwise the list is sorted by date and not by prospect. Enriching inventory data where the source is thin. Bringing portal leads together with the CRM, so that an enquiry through mobile.de does not end up in a mailbox while the same customer already has a history in the CRM. Which of these comes in which order is decided by the benefit in daily operation and not by the order of this list.
The shortest description of our position is this: AI helps here with the routine groundwork behind the sale, not with a chatbot on the home page. Someone considering a vehicle that costs tens of thousands of euros wants to speak to a salesperson and not to an assistant. And for everything that goes out to a customer — vehicle descriptions, suggested replies, printed data sheets — a person checks it before it leaves. This is not a rule for its own sake: a wrong note about equipment in a vehicle description is a binding statement, and the mandatory data has to come from the data record and not from a language model.
Four clients, seven projects — this is the strongest cluster in our portfolio: Autohaus Brüggemann with six locations on TYPO3, plus a Shopware 6 B2B shop and a CRM on a CCM2 basis; Nord Automobile in Rastede; Eschen Nutzfahrzeuge with our own etruck system; Dulle Mobile in the motorhome trade. The vehicle search on three of these websites is our own TYPO3 extension. Judge that by the reference pages and by the live websites, not by this answer.
The result set consists of one-off items, and the most important filters are ranges rather than selections: price, first registration, mileage, engine power. This makes the number of results the real feedback to the user — if you offer seven filters, they have to be combinable and fast, otherwise someone filters down to zero results and leaves. That is why the evaluation runs on the server, only the list is reloaded, and the result count updates with it.
That depends on the direction. If you want to maintain listings from outside — create, change, delete, assign images — that is the Seller-API, and it requires an API-Account; activation and access data go through mobile.de customer service. If you only want to read your own inventory and display it on your website, the Search-API through a Dealer-Account is enough. We ask this question at the start, because it decides which route is technically open at all — and because the activation sits with mobile.de and not with us.
In the dealer account at mobile.de: the dealer activates the Listing Integration there and generates an API user name and password. For registered dealers, access to their own inventory is usually included in the monthly fee. The dealer has to do this personally — we cannot apply for it on your behalf, but we will tell you exactly which values we need and what we need them for.
Yes, and that is the real reason for an interface. But one decision has to be made first: which system is the leading one, for each type of data? If the portal leads, the website is a copy of it. If your own system or your ERP leads, the portal is an output channel. Both variants work, but not at the same time for the same fields. We settle this in the concept phase, before the first line of code is written.
According to the documentation, parallel requests for the same listing are not allowed — updates have to be serialised. The maximum number of images per listing depends on the account. There are no published rate limits; for questions about volume, the documentation refers to support. In practice this means: a queue, a restart that continues where it stopped, and a log that shows which data record was transferred at which time and in which state.
Google Vehicle Ads show individual vehicles from commercial dealers directly in Google search results, with image, make, model, price, mileage and dealer name. The click leads to the vehicle detail page on your own website, not to a portal. On the status in Germany, Google contradicts itself: the announcement of 27 March 2026 states the format is available to all vehicle advertisers in Spain, Italy and Germany from March 2026, while the general overview page still lists Germany as an open beta requiring a contact form. We treat the dated announcement as the more recent source, but check the current state before any commitment.
Four building blocks: a Google Ads account linked to a Merchant Center account; a link to the Business Profile or, alternatively, a stored business data source; a vehicle feed in Merchant Center with all required attributes; and a campaign in Google Ads as Performance Max or standard Shopping. The feed is what matters. If your inventory already runs from an authoritative system to the website and the portal, the feed is one more output channel of the same source — otherwise it becomes a third data store, and those drift apart.
Documented, and stable across both Google sources, is the exclusion: commercial vehicles, agricultural vehicles, buses, motorcycles, boats and aircraft are not permitted, nor is any vehicle requiring a commercial driving licence. Heavy commercial vehicles therefore fall outside. Only direct sellers may take part, not intermediaries. The motorhome case is open: the policy page names motorhomes, campers and trailers as permitted, but Google own announcement limits that expansion to the United States from May 2026. We claim nothing here and settle it with Google before making any commitment — wrong information at this point costs a project.
Not as a finished package today. We are getting to grips with the format and preparing the data side — the feed from the authoritative system, attribute completeness, the image situation. If you want to start now, we talk about eligibility and the feed first and about the campaign after that. Selling a format we have not yet delivered in a client project as a mature service would not be honest.
By making fuel consumption, CO2 emissions and CO2 class mandatory fields in the data model and by having the import check them before writing. If a value is missing, the vehicle does not go online but into an error list that names the data record. That is inconvenient in daily work, but it prevents exactly the case you do not want. This is not legal advice: which vehicles in your inventory are covered, and how the figures have to be worded, belongs with your lawyer. We build the technology that makes it possible for him.
As one inventory with the location as an attribute, not as several websites. The location becomes a filter and a piece of information on the vehicle, including the contact person on site. A transfer between branches is then a change of one field and not a move of data records. Six locations run this way at Autohaus Brüggemann — Rheine-Mesum as head office, plus Brandenburg, Dortmund, Neubrandenburg, Rostock and Wietmarschen.
Yes, that is intentional. The filter states are in the address, for example search[make][], search[model][] and search[garage][]. A selection can therefore be sent, saved as a bookmark and used as a target for campaigns, QR codes or advertisements. If the same requirement only comes up after the launch, it is considerably more work — which is why we build it this way from the start.
Vehicle data is largely language-neutral: first registration, mileage, engine power, axle configuration. What gets translated is what is genuinely text — descriptions, equipment names, editorial pages. At Eschen Nutzfahrzeuge the website runs in five languages from a single data entry: German, English, Russian, Polish, Spanish. The effort does not lie in the number of languages but in the consistent separation of structure and translation.
We are working on this and we do not claim a finished product. The starting points we see: generating vehicle descriptions from equipment lists, pre-qualifying enquiries and assigning them to the right salesperson, prioritising follow-up tasks in the CRM, enriching thin inventory data, bringing portal leads together with the CRM. In other words, the routine groundwork behind the sale, not a chatbot on the home page. For everything that goes out to a customer, a person checks it before it leaves.
Because customer and vehicle belong together, and stay together for years: purchase, service, trade-in, follow-up purchase. Standard systems cover contacts, quotations and activities, but rarely the vehicle relationships that matter here. In the project at Autohaus Brüggemann, customer, company, vehicle and case are therefore separate objects with defined relationships, so that the history of a vehicle and the history of a customer can be viewed separately and together. The website, the B2B shop and the sales team are connected to it. The project is under development.
Our extension is a TYPO3 extension, so it does require TYPO3. If you are on a different system, that is not a decision made in advance: the first question is where your inventory is held and through which interface it can be reached. Only then can we say whether connecting to what you have is enough or whether a rebuild is the cheaper option. If a rebuild does not pay off, we will say so.
That depends on how many channels are involved, which system holds the inventory and what state the data is in. A vehicle import from a documented source is a different order of magnitude from your own inventory management with portal synchronisation, several locations and a CRM connection. We name a concrete figure after analysing your system landscape — before the project, not afterwards. And if a plan does not pay off, we say so instead of selling it.
Tell us which system holds your inventory today and which channels depend on it — portal, website, ERP, sales team. We will look at the state of your data and name a realistic effort for a connection. That also applies if the answer is that the rebuild is not worth it.