Car dealership agency
Sharpness Solutions is a digital agency in Oldenburg, Germany, founded in 1999. We have worked in the vehicle trade for years: the same TYPO3 vehicle search, built by us, runs at three dealers — from a commercial vehicle stock in the hundreds to more than two thousand cars at six locations. We are a partner of mobile.de and have built its interfaces in three projects: Eschen Nutzfahrzeuge, Autohaus Brüggemann and Nord Automobile. We are still working our way into Google Vehicle Ads: the format became generally available in Germany in March 2026, but we have not yet delivered it in a customer project. This page explains what happens in which order, what we deliver, what you have to supply, and what stays with mobile.de and Google. Phone +49 441 21 21 63 0, Mon–Fri 9:00–16:00 CET.
Requests from the vehicle trade sound different from each other and come down to four points. They are listed here so that you know before the first call what we will ask — and why we make no promise before these four points are settled.
The question sounds academic, and the cost of it surfaces later. As long as it is not settled per data type whether the portal, the ERP system or your own stock management holds the truth, two systems write the same fields. That does not show at first. It shows when a price on the website differs from the price in the portal, and nobody can reconstruct which value was the newer one. We settle this in the concept phase, before the first line of code.
Projects fail because of the account type before the technical work even starts. For the Seller API you need an API account, and mobile.de customer service enables it — not us, and not your dealer area. If you only want to read your own stock, the dealer account is enough for the Search API. You create those credentials yourself in the dealer area. Which path you need depends on the direction, and the direction depends on the first question.
Even after general availability, this is not a push-button job. Since March 2026 the format has been open to all vehicle advertisers in Germany, and you activate the add-on yourself in Merchant Center under Settings and Add-ons; a contact form and Google approval are no longer needed. What comes first is the eligibility question for your stock, and after it the work on feed and vehicle detail page. That is where the effort sits, not in the activation. We prepare the data side and tell you where our experience ends.
Google checks not only the feed but also the page behind it. Dealer name, location, price, mileage for used vehicles and availability must be visible there, and the price in the feed must match the price on the page exactly. If you show delivery costs in one view and hide them in another, or show mileage only in the result list, you produce rejections. This is work on the template and on the data model. It comes before a campaign makes any sense.
We are a partner of mobile.de. We have built the platform’s interfaces in three projects: at Eschen Nutzfahrzeuge, at Autohaus Brüggemann and at Nord Automobile — Autohaus is the German word for a car dealership, Nutzfahrzeuge for commercial vehicles. Across these three projects we know both directions from our own work: the export, where an in-house system writes the listings to mobile.de, and the import, where the portal stock is read into the website. Which direction runs at which customer we do not disclose here; that belongs to the customer. For your project the other question matters anyway: which direction fits your leading system. Both paths have run here, with the errors that come up along the way and with the effort they cost. And you will not get a promise from us that we copied out of the documentation: where mobile.de documents nothing — rate limits, for example — we say so instead of inventing a number.
The vehicle search on the websites of Autohaus Brüggemann, Nord Automobile and Eschen Nutzfahrzeuge is not a bought-in plugin. It is our own TYPO3 extension. The same extension, three very different stocks: used heavy commercial vehicles in the export business, a car centre with more than a thousand vehicles, and a multi-brand dealer with six locations and 24 brands in the filter. For you this has two practical consequences. First, the search is not a new development but an installation with adjustments. That moves the effort from programming to the data connection, which is where it belongs. Second, every further development benefits all installations: an additional filter criterion, an adjustment to changed mandatory information, an improvement in the result list. TYPO3 is the requirement. If you run a different system, that is not a decision against us, but it changes the calculation, and we say so before the offer.
At Eschen Nutzfahrzeuge we also run the stock management: etruck is our own development and the leading system there for stock, images and documents. The website is an output channel and not a second data store. The site runs in five languages from a single data entry, because technical values such as first registration, mileage and axle configuration are language neutral. It runs on our own servers in Germany. We mention this here not because a car dealership necessarily needs custom-built software — that question only comes up where standard systems cannot map the data model — but because it answers whether we have understood the data model of this industry or can only operate an interface. Anyone who has built a leading system knows which fields a portal connection really needs, and where an import silently loses values.
Before anything is built, one decision has to be made that no tool can make for you: which system leads the stock, and it has to be decided per data type. If mobile.de leads, your website is a mirror of the portal, and the stock is read through the Search API, which the documentation also calls Ad Integration. If your own system leads — your ERP system or a stock management system such as etruck — mobile.de is an output channel: listings are created, changed and deleted through the Seller API, and images are uploaded and sorted. Both work. Both at the same time for the same field does not work. If you skip this decision, you do not get an error message. You get two systems that overwrite each other: sometimes the import wins, sometimes the editor, and nobody can say which price is currently valid.
What the decision depends on can be named. First: where is a vehicle recorded first — in the portal or in your own systems? If you handle the car in purchasing, preparation and pricing anyway, the data is already internal and should not be entered a second time in the portal. Second: how many channels are there? With a website, a portal and a B2B channel, the import from the portal is a dead end, because the portal never holds all the fields the other channels need. Third: how deep is the data? A search result of the Search API returns fewer fields than the direct call of a listing through the ad key. That is how the documentation puts it, and it decides whether an import delivers the fields your vehicle detail page has to show at all. Fourth: which access do you have in the first place? That is decided by mobile.de, not by us — see the next section.
The decision produces the build plan. If your system leads, we need a queue rather than a burst of parallel calls: the documentation explicitly rules out parallel requests to the same listing, so anyone writing data and images at the same time has to serialise them per listing. Add a restart that does not begin at zero after a fault, and a log that shows which record was transferred when and in which state. If the portal leads, we need a robust reconciliation strategy instead. The Ad Stream delivers events by WebSocket when a listing is created, changed or deleted, but it keeps the history for only 24 hours. A longer outage cannot be caught up this way; a full reconciliation through another interface is then needed. These two components are the difference between a connection that runs and one that worked only once.
The access question comes first, because it decides which path is open at all — and because it is not ours to decide. mobile.de distinguishes two account types. Every registered dealer has the dealer account; the credentials for the interfaces released for it are created by the dealer in the dealer area. The API account is something else: a shared access for which individual interfaces are enabled, and the enabling runs through mobile.de customer service. According to the overview table in the documentation, the Seller API, the Ad Stream, the Insights API and the Lead API work only with an API account, while the Search API works with both, where the dealer account means access to your own inventory. So if you only want to read out your own listings and show them on the website, you do not need an API account enabled by support. We clarify this distinction before the offer, not during the implementation.
For the Seller API there are two documented paths, and they differ clearly. A dealer who uploads on his own — or his tool developer — applies for the release by email to mobile.de service, with the customer number concerned, the company name and the request to activate the Seller API. If the upload interface is activated, mobile.de creates an API user. The second path applies to transfer service providers, that is, to suppliers who serve many dealers. There the application requires company data, a technical and a contractual contact, information about software and platform, the postal address, the VAT identification number and at least ten customer numbers to be served. For a single car dealership the first path is the right one. The dealer has to apply for it; we cannot file it for you, but we tell you which information belongs in it.
The limits belong in the concept, not in the troubleshooting. Through paginated result pages the Search API returns at most 2,000 listings; the page size has a default of 20 and a maximum of 100. A larger stock has to be segmented by filters, otherwise it simply cannot be read completely. The Ad Stream allows one connection per user — if a second process opens a connection, the previous ones are closed, so an automatic reconnect belongs in the client. The maximum number of images per listing is not a fixed number: it is the field maxImages in the settings of the seller resource and has to be queried at runtime. Bulk requests of the Insights API take at most 100 mobileAdIds per endpoint, and up to 200 for the sales probability. Authentication throughout is by HTTP Basic Auth against services.mobile.de. And the test environment of the Ad Stream deviates on purpose: about one minute more delay and only ten percent of all events — it is not suitable for a load test.
What is not documented matters just as much. Rate limits, quotas or a defined behaviour under overload are not described in any of the five interface documents. Anyone who needs a volume commitment has to ask mobile.de for it; we claim none here. Image formats, minimum resolution and maximum file size on the portal side are not documented either — only the number of images through maxImages is described. There are also no availability or response commitments for the interfaces. And two interfaces are not open to everyone anyway: the Insights API is limited to participants in the data partner programme, the Lead API to registered transfer service providers and lead management partners, although a single dealer can use it for his own account. If someone sells you these points as settled, it is worth asking where the number comes from.
Google Vehicle Ads show individual vehicles directly in the search results, with an image and core data such as make, model, price, mileage and dealer name. The format addresses searchers who already have a specific vehicle in mind, and the click leads to the vehicle description page on your own website, not to a Google page. The current status: in Germany the format has been generally available since March 2026, released by Google on 27 March 2026 for all vehicle advertisers in Germany, Italy and Spain. It is also generally available in Australia, Canada, Japan and the USA. France, the Netherlands and the United Kingdom are still in open beta, and there Google still requires you to check the requirements, submit a contact form and wait for approval. For Germany this step is gone: you activate the add-on yourself in Merchant Center under Settings and Add-ons. Please note that Google’s own overview page still lists Germany as open beta — it is not up to date at this point.
The eligibility question decides whether the topic exists for you at all. Which vehicle types Google’s policy allows in detail and which it excludes is described at length on our industry page for the vehicle trade; we do not repeat the list here, but say what follows from it for a concrete stock. A pure passenger car stock is uncritical. A dealer with heavy commercial vehicles falls outside it, motorcycles and scooters as well. For motorhomes, quads and trailers the situation for the German market is open; the reason is in the next paragraph. With mixed stocks the separation is work on the data model: the feed has to exclude the ineligible items reliably, through a field that is maintained in the leading system, not through a manual selection before every submission. Anyone who adds this separation only after the first rejection builds the feed twice. Special cases we clarify with Google before we make a promise.
At this point Google contradicts itself, and we would rather say so than pass over it. The overview page for Vehicle Ads is narrower and apparently out of date: it limits the format to vehicles for non-commercial use such as cars and pick-ups, and lists as not allowed commercial vehicles, agricultural vehicles, buses, motorcycles, trains, boats, aircraft and outdoor utility vehicles. It does not name motorhomes explicitly and leaves open whether they fall under outdoor utility vehicles. The same page also still lists Germany as open beta, although the format has been generally available here since March 2026. The policy page has explicitly allowed motorhomes and camping vehicles since an update of 28 February 2025, on the condition of valid licences in the jurisdictions where the vehicles are located or sold — that update, however, is written in US terms. The extension to quads, UTVs and non-motorised trailers including camping vehicles was announced by Google from May 2026 explicitly for the USA only. We treat the policy page as the more specific source and clarify doubtful cases with Google before we make a promise.
On the seller side, only direct sellers are eligible; intermediaries are explicitly excluded. New and used vehicle stock from dealers, retailers, aggregators or manufacturers is allowed, where aggregators and manufacturers may only submit vehicles of licensed dealers. You need a valid dealer licence where the law requires one, and a physical location that customers can visit to inspect or buy the vehicle. Google’s policy also requires proof of clear title to the vehicle, that is, ownership free of encumbrances — the wording comes from US title law, and how it applies to German vehicle papers we clarify with Google in case of doubt. On the account side, Google requires four things: verify and claim the website through the Business Profile, link the Google Ads account with Merchant Center, link the Business Profile, and enter the company data in the dealer profile. If you do not own the dealer locations, you submit a dealer data source instead. There is no separate campaign type: for Germany Google names delivery through Performance Max with vehicle data sources.
Part of the work does not concern Google but your own website. Dealer name, dealer location, vehicle price, for new vehicles the recommended retail price, the vehicle identification number, for used vehicles the mileage and the availability have to be visible on the vehicle detail page. And the price in the data source has to match the price on the page exactly — not roughly, not with a different decimal, not with or without delivery costs depending on the view. The same rule applies to the mileage. The linked page has to be reachable, has to show the advertised vehicle correctly and has to state the availability accurately. If you work with link templates, the template has to contain the parameter for the store code and has to lead to the specific vehicle page. This is work on the template and on the data chain, not on a campaign.
The feed itself is a manageable but unforgiving list. Mandatory are, among others, the id, the product category, the fulfilment type, for local offers the store code and a link template with a store code placeholder, for online offers the link, plus image link, price, condition, make, model, mileage and colour. For Germany the vehicle identification number is not mandatory in the feed; where it is submitted, it has to be unique per vehicle. The mileage is explicitly mandatory for vehicle feeds, and always with a unit — the allowed notations are narrow, and the value has to match the statement on the landing page. Depending on country and condition, further fields are added: year of manufacture, price type, list price, engine, date of first registration for used vehicles, fuel consumption and CO2 emission. For German emission certifications there is a separate attribute. The vehicle data source can be submitted as a file, as a Google Sheet or through the Merchant API; in the configuration the destination for Vehicle Ads has to be enabled.
Images are the third stumbling block. Allowed are GIF, JPEG, PNG, BMP and TIFF, at least 100 by 100 pixels, recommended 800 by 600 in the aspect ratio 4:3, at most 16 megabytes and 64 megapixels. Overlaid watermarks, inserted logos and text are forbidden; cropped images are rejected. Placeholder or catalogue images are allowed only for new vehicles, and even then only if make, model and colour match the listed vehicle. If you have been putting a logo on your vehicle photos, you have work to do here. On the schedule: after submitting or updating a data source, synchronisation and review take 24 to 48 hours, and the store code in the vehicle feed has to match the one in the dealer data. Google names no costs or minimum budgets in the documentation; therefore we do not name any either.
Process
Send us the URL of your vehicle search, your mobile.de customer number, or simply the question you are stuck on. You get a written assessment of which system should lead, which portal access is needed and whether your stock is eligible for Google Vehicle Ads at all — even if you place the order elsewhere afterwards. Sharpness Solutions GmbH (a German limited liability company), Edewechter Landstraße 161, 26131 Oldenburg, Germany. Phone +49 441 21 21 63 0, Mon–Fri 9:00–16:00 CET, info@sharpness.de.
We look at which systems are in use at your company: ERP or dealer management system, website and CMS, portal accounts, any B2B channel, the CRM. Then the data situation — which fields exist, where fuel consumption, CO2 figures and images are stored, who records a vehicle first. The result is a list of the systems with their interfaces and open points. You get it in writing, even if you do not place an order afterwards.
Before the technical work comes the decision, per data type: who holds master data, who holds prices, who holds images, who holds the sold status. From this follows the direction of the portal connection — export through the Seller API or import through the Search API — and with it the account type you need. We write this down as a table, field by field. Later that table is the reference when someone asks why a value was not overwritten.
Now you apply for what only you can request. At mobile.de that is, depending on the direction, the API account through customer service or the dealer account, whose credentials you create in the dealer area. At Google it is Business Profile, Merchant Center and the Google Ads account; since general availability in Germany you activate the Vehicle Ads add-on yourself in Merchant Center, with no contact form and no Google approval. We tell you which details belong in the application, and we wait to build until the access is there.
Then we build: the data model along vehicle logic, the vehicle search as our TYPO3 extension with your filters, and the portal connection in the defined direction. That includes a queue, a restart and a log per record, because parallel requests to the same listing are ruled out and a failed run would otherwise not be traceable. Mandatory fields are checked before writing: incomplete means error list, not online. We test against a real section of your stock, not against invented records.
If Vehicle Ads are the goal, the work on the detail page follows: dealer name, location, price, mileage for used vehicles and availability visible, price and mileage identical with the feed, link template with store code, images without logo and without watermark. In parallel we check the eligibility question for your stock and clarify doubtful cases with Google. Only once feed and page match does a Performance Max campaign become a topic at all.
You test on staging against an acceptance list: import and export runs, removal of sold vehicles, filters, mandatory information, forms, redirects. The go-live runs in the agreed window with backup and a documented way back. After that comes the question who takes over ongoing maintenance. Without a service level agreement we handle requests in order of arrival within 48 hours during business hours, Mon–Fri 9:00–16:00 CET; with an agreement, BASIC 24, STANDARD 8, ADVANCED 4 or PREMIUM 2 hours response time apply, net monthly fee per project on request.
Yes. We are a partner of mobile.de and have built its interfaces in three projects: at Eschen Nutzfahrzeuge, at Autohaus Brüggemann and at Nord Automobile. Through these projects we know both directions from our own work — the export, where an in-house system writes the listings to the portal, and the import, where the portal stock is read into the website. Which direction runs at which customer we do not disclose; that belongs to the customer. For your project the other question is decisive anyway: which direction fits your leading system. We clarify that before the offer, not during the implementation.
That depends on the direction, and the answer is already in the question about the leading system. If your system leads, we write to the portal through the Seller API; for that you need an API account. If the portal leads, we read through the Search API, which the documentation calls Ad Integration; for that the dealer account is enough. The difference that counts in the offer is not the name of the interface but the effort behind it. The export needs a queue, a restart and a transfer log, because parallel requests to the same listing are ruled out. The import needs a reconciliation strategy and, before that, a check whether a search run delivers all the fields your detail page has to show.
You do. The release lies with mobile.de and with the dealer, not with the agency. For the Seller API, a dealer who uploads on his own applies for activation by email to mobile.de service, with the customer number, the company name and the request for release; on activation an API user is created. Suppliers who serve many dealers go through the transfer service provider application with company data, a technical and a contractual contact, the VAT identification number and at least ten customer numbers. For the dealer account you enable Listing Integration in your dealer account and create the API user name and password there. We go through this step together in your account.
Through paginated result pages at most 2,000 listings are reachable. The page size has a default of 20 and a maximum of 100 — with 100 per page that is 20 pages. If you want to read a larger stock completely, you have to segment by filters, for example by make, category or modification date, and merge the segments cleanly. There is a second limit that matters more in the concept than the first: a search result returns fewer fields than the direct call of a listing through the ad key. Whether the fields of your detail page can come out of a search run at all is something we check beforehand on real records.
The documentation says nothing about that. For none of the five interfaces — Seller, Search, Ad Stream, Insights, Lead — are rate limits, quotas or a defined behaviour under overload described. If you need a volume commitment, you have to ask mobile.de for it; we do not invent one. Four concrete limits are documented, however: one Ad Stream connection per user, the cap of 2,000 results in the Search API, at most 100 mobileAdIds per bulk request of the Insights API — up to 200 for the sales probability — and the ban on parallel requests to the same listing in the Seller API. Our implementation therefore builds on a queue with restart, not on a presumed upper limit.
That is not a fixed number but an account setting. The maximum number of images is the field maxImages in the settings object of the seller resource. It therefore depends on the account and can change; the examples in the documentation show the values 15 and 30. In practice this means the client has to query maxImages at runtime and align the image set with it, instead of hard-wiring a number. Image formats, minimum resolution and maximum file size are not documented for the portal interface, by the way — unlike at Google, where there are clear requirements for them.
In Germany the format has been generally available since March 2026: Google released Vehicle Ads on 27 March 2026 for all vehicle advertisers in Germany, Italy and Spain. They are also generally available in Australia, Canada, Japan and the USA; France, the Netherlands and the United Kingdom are still in open beta. Only there does Google require a contact form and an approval before activation — for Germany you activate the add-on yourself in Merchant Center under Settings and Add-ons. Please note that Google’s overview page still lists Germany as open beta; it is not up to date at this point. What the format shows and where the click leads is described in the section on Vehicle Ads above.
Google’s policy decides that, and the check belongs at the beginning. The line does not run between brands but between vehicle types and seller types: a pure passenger car stock is uncritical, a dealer with heavy commercial vehicles falls outside it, motorcycles and scooters are out. Only direct sellers are eligible, with a valid dealer licence where it is required and with a location that customers can visit. With motorhomes, caution is needed: the inclusion of camping vehicles, quads and trailers has so far been announced by Google only for the USA; for Germany it is unsettled. In practice we go through the categories of your leading system and define which go into the feed and which do not. Doubtful cases we clarify with Google before we make a promise.
We go by the policy page, because it is the more specific source — and we tell you that the contradiction exists instead of passing over it. The details are in the section on Vehicle Ads above. Decisive for your planning is the second point: the extension to quads, UTVs, trailers and camping vehicles was announced by Google explicitly for the USA only, and the older update on motorhomes is written in US terms as well. For a motorhome project this means we plan the feed so that the affected categories can be taken out of the submission with a single switch, and we obtain the information from Google before any effort for campaigns is planned. As long as it is not available, the format is not part of our offer for these vehicles.
Dealer name, dealer location, vehicle price, for new vehicles the recommended retail price, the vehicle identification number, for used vehicles the mileage and the availability. On top of that comes the consistency rule: the price in the data source and in the structured data has to match the price on the page exactly, and the mileage as well. The linked page has to be reachable and has to show the advertised vehicle correctly. If you work with link templates, the template has to contain the store code parameter and has to lead to the specific vehicle page. That is why a Vehicle Ads project starts with us as a website and data project and not as a campaign project.
No, the vehicle identification number is not mandatory in the feed for Germany; it is also optional for France, Italy, Japan, Spain, the Netherlands and the United Kingdom, and for vehicles on order. Where you do submit it, it has to be unique per vehicle. Mandatory, by contrast, is the mileage, and always with a unit — the allowed notations are narrow, and the value has to match the statement on the landing page. This distinction is typical for the feed: one part of the attributes is mandatory everywhere, another only depending on country or condition. Which fields your stock can actually deliver is something we check before the submission.
No, not as a finished package today. The format has been generally available in Germany since March 2026, but we have not yet delivered it in a customer project — so we tell you where our experience ends instead of selling a routine service. What we deliver today is the data part: the feed from the leading system, the mandatory attributes, images without logo and watermark, the store code in the link template. Plus the order that determines the effort: first the eligibility question, then feed and vehicle detail page, and only after that a campaign. Google names no costs or minimum budgets in the documentation; we therefore do not name any either.
Not necessarily. Our vehicle search is a TYPO3 extension and to that extent requires TYPO3 — but the search is the second question, not the first. First we clarify where your stock is held and through which interface it is reachable. If your existing system can be connected on the data side, we build the data chain and leave the website as it is. If it does not hold the vehicle data in a structured form, we weigh a connection against a rebuild and put both paths in front of you with the effort for each. If a rebuild does not pay off, we say so.
We name an effort after the system inventory, not before — it depends on the number of channels, on the leading system, on the state of the data and on whether Vehicle Ads are added. For the operation afterwards: without a service level agreement we handle requests in order of arrival within 48 hours during business hours, Mon–Fri 9:00–16:00 CET. With an agreement there are four levels — BASIC with 24, STANDARD with 8, ADVANCED with 4 and PREMIUM with 2 hours response time, billed as a net monthly fee per project or shop. We name the prices on request, because they depend on system size, number of interfaces and stock.
Enquiry
Tell us where your stock is held and what should arrive on the website. You get a written assessment of the leading system, the portal access and the eligibility question — even if you place the order elsewhere afterwards.