Kevel Integration for Car Dealers

An ad server you operate rather than a place to buy audience, and what that changes about the request.

Kevel sells the machinery behind an ad server rather than the audience an ad server fills. Its APIs decide which ad belongs in a given slot, hold the flight rules, count the impressions and hand back a decision in milliseconds. Publishers and marketplaces use it to stand up sponsored placements on their own properties without writing a decision engine from scratch.

For a dealership that framing matters, because it is the reverse of every other entry in this catalogue. Everywhere else you arrive with a budget and leave with impressions. Here you arrive with placements you already own and leave with a way to sell them. The product is developer facing: documented APIs, software development kits in the usual languages, and a decision endpoint your own site or app calls.

The practical translation is that Kevel is relevant to a dealer group running its own audience destination, a service portal, or an internal retail media layer across many rooftops. It is not relevant to a single store buying reach, which is what programmatic display is for.

The case for standing up an ad server is that a dealer group with real traffic is currently giving that attention away for nothing. A twenty rooftop group's inventory pages, service scheduler and owner portal add up to a serious monthly audience, and lenders, warranty providers, tire brands and insurers all pay to reach exactly that person at exactly that moment. Kevel is how that becomes a revenue line rather than an idea in a slide.

The honest objection is that almost no dealership should be doing this. An ad server is not a marketing purchase, it is a product you now own and maintain: creative trafficking, flight scheduling, reporting your advertisers will argue with, an invoicing process, and somebody answering the phone when a campaign underdelivers. The cost is not the licence, it is the headcount. Below a certain volume of owned traffic the revenue never covers the salary, and the same effort spent on the group's own advertising would return more.

The second objection is simpler and it is the one that ends most conversations. Kevel supplies no demand. It decides which ad to serve. Finding the advertisers who pay for those slots is entirely your problem, and selling media is a different business from selling cars.

Not started. The published test for that status is blunt: no adapter file exists in the LeadLocate ad gateway for this platform. There is no authorization URL, no wire-up checklist, no half written token exchange. Nothing.

Access class is PUBLIC, which is the vendor's gate rather than ours. Kevel documents its developer APIs and software development kits openly and does not run credentials through an approval queue, so if this were built the credential step would be ours to complete rather than a review we would sit and wait on. That is unusual on the request side of this directory, where most entries carry a vendor application in front of them.

The more interesting fact is that an open vendor gate has still not been enough to get this built, and the reason is shape rather than difficulty. Our gateway describes a buy side relationship. Every operation in it assumes a network we spend money with. Kevel sits on the other side of that transaction, so an adapter here would not be a fill in the blanks exercise against an existing interface. It would be a second interface, and nobody has yet asked us to design one.

Stated as a hypothesis rather than a description, because none of this runs and no code path in the CRM reaches this vendor.

Read that last row as a property of the whole product rather than a limitation of this page. It is true of every platform in this directory, including the one that is connected, and the section below names each piece of it.

Kevel would not be wired into the CRM as a special case, and that is precisely where it gets awkward.

Inside LeadLocate there is one library defining what an advertising platform must be able to do: hand us an authorization URL, exchange the code for a token, list the accounts you own, deploy a campaign, pause or resume it, return spend and results, and prove on demand that the connection still works. Seven operations, one adapter file per network. That contract is why adding a network is scoped work with a checklist rather than an open ended project, and why turning one on does not disturb the network already running.

Now read those seven against an ad server. Six of them bend. Deploying a campaign becomes trafficking a flight. Returning spend becomes returning delivery, and the money moves toward the dealer group instead of away from it. Pause and resume survive unchanged. That mismatch is an engineering answer rather than an excuse, and it is why this page reads differently from its neighbours in the directory.

Everything underneath the contract would carry over untouched. Tokens are encrypted with AES-256-GCM before storage. Every action against a network is written to an append only audit log carrying the company, the network, the user and the detail, stamped in UTC because these tables are shared across dealerships. Campaign objects record which credentials created them and re-resolve those same credentials later, so disconnecting an account does not strand the work built under it.

There are two ways to advertise through LeadLocate and you pick. The first is the webXintel Ads Network. It is included, our team builds and runs the campaigns from the selections you make in Leads Manager, and it arrives as one line rather than a stack of platform invoices. Nothing to configure and no developer application to file.

The second is your own account. Connect the advertising account your store already has and campaigns route through it instead, on your billing, in your name, with your spend history intact. Most vendors will not offer the second option, because it costs them the markup on your media.

Kevel does not sit cleanly in either column, and pretending otherwise would be the sort of thing this directory exists to avoid. An ad server is not a media buy, so there is no managed version of it and no campaign to route anywhere. What a group asking for Kevel actually wants is for LeadLocate to operate a sell side stack on its behalf. That is a real conversation and it is not the conversation this catalogue was built around.

One limit applies across the whole gateway regardless of path: pushing, pausing and reading numbers from a network is done by our team today, not from your dashboard.

The first step is not code. Somebody has to decide that LeadLocate should carry a sell side contract at all, because the seven operation interface described above does not describe an ad server, and stretching it until it does would make every other adapter worse. That is a product decision with a cost attached to it, and it is the real gate here.

If that decision went the right way the rest is ordinary work. Register a developer application, which for this vendor needs no approval. Fill a credential block in the configuration file and enable it. Implement the credential handshake. Implement the object calls that create placements and flights. Implement delivery reporting. Implement a verification call that proves the connection is alive rather than assumed.

What a group would see afterwards is not lead volume. It is a fill rate, a delivery report, and an invoice you send rather than one you pay. It takes a sales cycle to produce anything readable, because the constraint is advertisers signed rather than impressions available. That is a slower and less certain loop than anything else in this directory, and any timeline offered for it before the demand exists would be invented.

No adapter exists, so the honest list on this page is short and absolute.

We have never made a call to this vendor from the CRM. Not in production, not in testing, not in a prototype somebody wrote and abandoned. There is no code path that reaches it.

We do not emit a vehicle catalog. An ad server that merchandised your units would want a product feed, and nothing anywhere in our stack generates one for any platform. Inventory Link ingests your feed and merchandises your units on your own properties, which is a different thing entirely and is not a catalog handed to an advertising system.

We do not install or manage pixels, we do not run a server side conversions endpoint of any kind, and we do not upload offline conversions. Those are absent from the whole product, not merely from this page.

We do not export a hashed audience. Targeting built from a dealership's own customer list has no export anywhere in what we sell.

A dealer cannot push, activate, pause or read spend on any network without our team. That is true of the single platform we have connected and it would be true here on day one.

Say so, and say what you are actually trying to do, because on this page those are two different questions. A single rooftop asking for Kevel almost always wants something else: better return from the media it already buys, or a way to merchandise its own inventory to its own visitors. Both of those are answered elsewhere in the product and neither one needs an ad server.

A dealer group with real owned traffic and a genuine plan to sell placements across its rooftops is a different conversation, and it deserves a person rather than a form. Requests are recorded against the platform they name, and the tally is the input to build order, because a request from a group ready to commit is a better signal than any roadmap meeting. Naming this vendor specifically is what moves it.

In the meantime the managed path runs today and waits on none of this. Pricing for the platform is on the pricing page and does not change based on which networks you turn on.

Does LeadLocate integrate with Kevel today?

No. The published test for that status is that no adapter file exists in the ad gateway for this platform, and none does. There is no authorization URL, no checklist and no code path in the CRM that reaches this vendor.

Can I use my own Kevel account?

Not through the CRM. There is nothing to connect an account to. If your group already runs an ad server, it keeps running exactly as it does now and LeadLocate neither helps nor interferes.

What happens if I request Kevel?

It is recorded against this vendor specifically and counted, and the tally decides build order. Because this one would need a second interface rather than another adapter, you will also get a call rather than a queue position, so we can find out what you are really trying to sell.

Is Kevel somewhere I can buy advertising?

No, and this is the most common misreading of the entry. It supplies no demand and no audience. It decides which ad fills a slot on a property you already own, which means you still have to go and find the advertisers who pay for those slots.

Would connecting this let you serve my inventory as ads?

No. Any inventory driven ad product needs a vehicle catalog fed to the advertising system, and we do not generate one for any platform. That gap is completely separate from whether an adapter exists, and building the adapter would not close it.

The access class says PUBLIC. Does that mean it is easy to build?

It means the vendor is not the obstacle. Credentials are openly documented and there is no approval queue, so nothing here waits on somebody else's review. The obstacle is on our side and it is a design question, not a paperwork question.

Requests are counted against the platform they name. If your group has owned traffic and a plan to sell placements across it, that is a conversation with a person rather than a queue position.