Sharethrough Integration for Car Dealers

Native inventory at exchange scale, and a candid explanation of why most stores should ask for something else.

Sharethrough is an advertising exchange with a native specialism. Its business is the supply side: it represents publishers, packages their in feed and in article placements into standardised formats, and makes that inventory available programmatically to buyers who bid for it through demand side platforms. It also invests heavily in the format itself, including enhanced native units and lower carbon delivery paths.

The distinction from a native network matters enormously for a dealership, and most vendor pages blur it. A native network sells you a product: you open an account, you write a headline, you fund a deposit, clicks arrive. An exchange sells access to inventory, and the buying happens somewhere else. There is no self serve dashboard where a store manager opens a campaign and starts spending on Tuesday.

So the accurate dealership translation is that this is a source of inventory that already sits underneath the programmatic buys a store may be running. If your group is buying native and display through a demand side platform, a share of what you have already purchased very likely came through this exchange without anybody naming it on the invoice.

The case, stated properly, is format quality at exchange scale. Native inventory bought through an exchange with a genuine specialism in the format tends to render better and sit in better positions than generic display bought on price, and for a group running programmatic at volume that is a real difference in performance rather than a talking point.

The honest objection is bigger than usual on this page, and it is that most stores are asking the wrong question when they ask for this. A supply side platform is not somewhere a dealership buys directly. Requesting it as an integration is, nine times out of ten, a request for programmatic reach that would be better aimed at a demand side platform, and any vendor who takes the request at face value without saying so is selling rather than advising. The honest steer is toward programmatic display advertising for dealers first.

The second objection is duplication. A group already buying programmatically reaches this inventory today. Adding a named path to supply it already has is work that produces reporting clarity rather than new reach, which is worth something but is not what the request usually intends.

The third is brand safety at exchange scale. Inventory lists, category blocks and viewability floors remain the buyer's job, and exchange scale means more of them.

Not started. The published test is that no adapter file exists in the ad gateway for this platform, and that is exactly the situation. No authorization URL, no credential block, no wire-up checklist and no partially written code. It is a catalogued name with an honest status attached.

Access class is PARTNER, and that gate is the vendor's rather than ours. Credentials come through an application the vendor reviews, which is the normal shape of a supply side relationship, since the parties an exchange transacts with are typically buying platforms rather than individual advertisers. That is another way of saying the same thing the section above says: the structure of this business does not point at a single dealership.

Publishing this at request status rather than quietly omitting the platform is deliberate. A directory that only lists what a vendor has built tells a dealer nothing about the things it has not, and the eighty entries in this position are the reason the twenty that say something stronger can be believed.

Written as a design for a connection that does not exist, and worth reading for what is absent as much as for what is present.

Lead capture would be clickout, as it is across this whole family. There is no form inside a native unit, so the opt in happens on a page you control using forms that already exist in the CRM, and the landing page carries the entire burden of turning a cold click into a contact.

The reason a platform with no code can still be described exactly is that the gateway it would join is already built and does not change per network.

A single library inside LeadLocate defines what any advertising platform must be able to do: hand us an authorization URL, exchange the credential for a usable token, list the accounts that credential reaches, 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 shape is also why the structural objection above is not a dodge: the seven operations assume a buying relationship, and a supply side platform does not naturally provide one.

Credentials are encrypted with AES-256-GCM before storage. Every action against any network is written to an append only audit log carrying the company, the network, the user and the detail, timestamped in UTC because the table is shared across dealerships and a company local timestamp cannot be reconciled later. Campaign objects record which credentials created them and re-resolve those same credentials afterwards, so disconnecting an account does not strand the work built underneath it. That machinery is what a request buys a place in the queue for.

Two ways to advertise through LeadLocate, and the store decides which.

The first is the webXintel Ads Network. It is included, our team builds and operates the campaigns from the selections you make in Leads Manager, and it arrives as a single line rather than a stack of platform statements. No application to file and no credential to hold.

The second is your own account, where campaigns route through the advertiser account your group already holds, on your billing, in your name, with your history intact. For this platform neither route exists today: there is no adapter, and the vendor gate has not been approached, which is the plain answer rather than a soft one.

One boundary that applies across the whole gateway: deploying, activating, pausing and reading spend is done by our team today rather than by a control on your screen. That is a deliberate constraint while the connection layer is young.

Before any of the usual steps, this platform needs a decision that the others do not: whether a direct buying relationship is the right shape at all, or whether the same inventory should be reached through a demand side platform that already bids into it. That question is worth answering honestly before engineering time is spent, because the wrong answer produces a working connection nobody has a reason to use.

If the answer is yes, the sequence is the standard one. A request from a store that would fund it. A queue position earned against the rest of the catalogue. An adapter file written against the seven operations with a credential block and a verification path. And a vendor reviewed application, which runs on somebody else's timeline.

On measurement, native clicks are readable within hours of delivery starting, which is the usual pattern in this family. Turning those clicks into contacts takes days rather than hours, because the opt in happens after the click on your own page. Both are statements about how fast the channel becomes readable rather than predictions of volume, and the number of leads a store gets is not something any vendor can honestly forecast for you in advance.

Nothing is connected, so the list is short and blunt.

We have never made a call to this platform. No adapter file, no credential, no verification and no deployment. Nothing has been written against the seven operations for it.

We do not emit a vehicle catalog or an inventory feed to this or any advertising platform, so dynamic vehicle creative in native units is not something we deliver anywhere in this directory.

We do not run a server side conversions API, we do not upload offline conversions, and we do not install or manage pixels. Programmatic buying optimises toward a signal, and that signal would not be coming from us.

We do not export a hashed customer list for matching, suppression or lookalike building, which rules out the audience led use case people most often have in mind when they ask about an exchange.

We do not operate a demand side buying desk. Inventory allow lists, category blocks, viewability floors and frequency policy are judgement calls somebody has to own, and an adapter moves campaigns rather than making decisions.

Ask for it by name if you have a specific reason, and tell us the reason, because on this platform the reason changes the answer more than the request does. Requests are recorded against the platform they name and the tally sets build order across the catalogue, so nothing is lost by asking.

What helps most here is describing the outcome instead of the vendor. If what you want is native reach at scale across the open web, say that, and the queue may point at a buying platform rather than at an exchange. If you specifically want this exchange because a demand side platform you already use reports it as your best performing supply source, say that too, because it is the strongest version of this request and it is rare enough to move the order.

The managed path runs today and waits on none of it. Platform pricing is on the pricing page and does not change with which networks you turn on, and the rest of the catalogue with its statuses is on the advertising overview and in this directory.

Does LeadLocate integrate with Sharethrough today?

No. The status is not started, and its published test is that no adapter file exists in the ad gateway for this platform. There is no credential, no checklist and no partial code, and demand is what would change that.

Can I use my own Sharethrough account?

Not through the CRM, and for most stores the question is worth reframing. Access is partner gated, so credentials follow an application the vendor reviews, and an exchange normally transacts with buying platforms rather than with individual advertisers.

What happens if I request Sharethrough?

It is recorded against this platform by name and counted, and the count feeds build order. A person answers with a range or a reason. On this platform the reply will usually also ask what outcome you want, because a buying platform may serve it better.

Am I already buying this inventory without knowing it?

Quite possibly. If your group runs programmatic native or display through a demand side platform, some of that delivery is likely to have come through this exchange. A named connection would give you clearer reporting rather than genuinely new reach.

What is the difference between an exchange and a native network?

A native network sells you an account, a dashboard and clicks. An exchange represents publishers and offers their inventory to buying platforms. The first is something a store can operate directly. The second sits underneath whatever your buying platform purchases.

Would connecting this improve my lead volume?

Not by itself. Native units capture no lead directly, so the opt in still depends on the landing page behind the click. Reporting clarity and format quality are the honest benefits, and neither of them is a volume claim.

Requests are recorded against the platform they name and the tally sets build order. Tell us the reach you are missing and which buying platform your group already uses.