Bidtellect Integration for Car Dealers

A placement level native buying platform, and an honest account of what our ad gateway does and does not do with it.

Bidtellect is a demand side platform built around one format instead of all of them. A general purpose DSP treats native as a checkbox sitting beside display, video and audio. Bidtellect was designed the other way round, with in-feed units, content recommendation modules and sponsored article placements as the product, and everything else arranged behind that decision.

The consequence that matters to a store is where the optimization happens. Most buying platforms tune toward a site or an exchange. Bidtellect tunes toward the individual placement, which is the specific slot on a specific page, and it does that because native inventory varies enormously inside a single publisher. The unit at the foot of a long review article and the unit halfway down a listicle behave nothing alike, and a system that averages them together buys the bad one at the price of the good one.

For a dealership the practical translation is an ad that runs inside the body of a page somebody is already reading, styled to match the type around it, rather than a banner the reader has spent a decade training themselves not to see.

The argument is attention at a price search cannot match. A native unit inside an article gets read rather than skipped, cost per click sits far below what an automotive search auction charges, and the granular placement controls mean a careful operator can prune the inventory that produces clicks and no time on site. If your goal is to put a service special, a trade appraisal offer or a new model launch in front of people in your county who are not currently searching, this is a reasonable way to buy it.

The honest objection is intent, and it is a big one. Nobody reading a recipe or a sports recap is in the market for a truck at that moment. This traffic arrives colder than anything you buy on social lead forms, and far colder than search. Treated as a lead channel it will disappoint. Treated as a way to get a store in front of a defined trade area cheaply, and judged on that, it holds up.

The second objection is operational. Placement level control is only an advantage if somebody actually uses it. An account nobody prunes drifts toward the cheapest inventory available, which is cheap for reasons. That is labour, weekly, and it should be priced into the decision before the media is.

Available on request, which is the weakest of the three statuses in this directory and the honest one here. The published test for it is that work has not started. There is no Bidtellect adapter file in the ad gateway, no credential block, no authorization URL and no checklist. Nothing exists that a dealership could be shown.

Access class is PARTNER, and that is the vendor's gate rather than ours. Bidtellect issues API credentials after an application it reviews, which means even a finished adapter would sit behind an approval we do not control. That matters for sequencing: on a platform where anyone can self register, our engineering is the only variable. Here there are two, and one of them belongs to somebody else.

We publish that rather than quietly listing a logo, because a logo on an integrations page reads as a connection to every dealer who sees it. If you are comparing vendors, ask each of them what the word beside the logo is tested against. The directory index states ours on every entry.

Written as a design, not a description, because none of it runs. This is the shape any network takes once it is wired into the gateway.

The last row is not a limitation of Bidtellect. It is a statement about us, and the section further down says the same thing without the table around it.

The reason a page like this can be specific about work that has not started is that the shape of the work is already fixed.

Inside LeadLocate there is one provider agnostic library defining what any 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. Adding a platform is filling in that file, not designing a system, and turning one on does not disturb any network already answering the same contract.

The parts that usually take the longest are already built and shared. Access credentials are encrypted before storage using AES-256-GCM. Every action taken against a network is written to an append only audit log carrying the company, the network, the user and the detail, stamped in UTC on purpose, because these tables are shared across dealerships and a timezone relative timestamp is one nobody can reconcile afterwards. Campaign objects record the credentials that created them and re-resolve those same credentials later, so a store that disconnects an account does not strand the work built underneath it.

Twenty networks are registered against that contract. One is implemented. Every other adapter returns a refusal naming itself, so a stray call fails loudly instead of looking like an outage at the network.

Two paths, and a store picks one. The first is the webXintel Ads Network. It is included, our team builds 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 set up, no developer application to file, and it does not wait on anything described on this page.

The second path is your own advertiser account. Where an adapter exists, you authorize it once and campaigns route through your account, on your billing, in your name, with your spend history intact. For Bidtellect that path does not exist yet, and a store that already buys native through an agency would keep doing that unchanged.

One limit stated plainly, because it is true across the whole gateway and you would find out anyway: pushing, pausing and reading spend from a network is done by our team, not from your dashboard. That is a deliberate constraint while the connection layer is young, and opening it up is on the list.

Four things, in order. File the advertiser application with Bidtellect and wait for the review that produces credentials. Add the credential block and write the adapter against the seven operations. Implement campaign deployment and reporting against the placement level endpoints, which is where the real work sits, because a native buy without placement reporting is a buy nobody can prune. Then verification, so the connection can be proven rather than assumed.

The first step runs on the vendor's timeline. That is the difference between a PARTNER platform and a public one, and it is the honest reason a request here is a slower promise than a request on a self serve network.

Once live, native demand side buying reads slowly compared with search or social. Click data arrives immediately and means very little. Useful signal is placement level, and a placement needs enough impressions before its numbers separate from noise, so a fair first read is a couple of weeks rather than a couple of days. That is a statement about how quickly the channel produces information, not a promise about lead counts. No vendor can honestly make that promise, and the ones who do are telling you something about themselves. Our page on what to expect from car sales leads covers that argument in full.

Bidtellect supports things we have not built, and this is the section where they get named rather than left vague.

We do not emit a vehicle catalog to any advertising platform. Dynamic native units that render a specific VIN with its price and mileage run from a product feed, and no code in our stack generates one. Inventory Link ingests your feed and merchandises your units on your own properties, which is a different thing.

We do not install or manage pixels, and we run no server side conversions API. Native buying leans hard on a conversion signal coming back from the landing page, and that signal is not something we supply. Nor do we upload offline conversions once a deal closes.

We export no hashed audience. A customer list matched into a platform for targeting or suppression is a real capability on the buy side and we have no export that produces one.

There is no native lead form to retrieve here, and our form retrieval exists for one network only, so any lead from this channel arrives through a landing page you control. No campaign has ever been deployed from the CRM to Bidtellect, because the code that would do it does not exist.

Ask, and attach the store name. Requests are recorded against the platform they name, and the tally is the input to build order, because a dealership ready to spend on a channel is a better signal than any roadmap meeting. You will hear back from a person with a range or a reason rather than silence, and if the honest answer is that a PARTNER application makes it slow, that is what you will be told.

If what you are really buying is native reach rather than Bidtellect specifically, say that instead. It is a different and usually faster conversation, and it overlaps heavily with what a store buys through programmatic display. Meanwhile the managed path is available now and does not depend on any adapter work here.

Pricing for the platform is on the pricing page and does not change based on which networks you turn on.

Does LeadLocate integrate with Bidtellect today?

No. Bidtellect is available on request, which in this directory means work has not started: no adapter file, no credential block, no checklist. The request queue decides which platforms move off that status and in what order.

Can I use my own Bidtellect ad account?

Not through the CRM, because there is nothing to authorize against yet. If your store already buys Bidtellect through an agency, that arrangement is untouched by anything here and keeps running exactly as it does now.

What happens if I request Bidtellect?

It is recorded against Bidtellect specifically and counted, and that count feeds build order. Because this platform is PARTNER gated, the answer you get back will separate our engineering time from the vendor application, which is the part we do not control.

What does PARTNER access mean here?

It means the vendor reviews an application before issuing API credentials. It is the vendor's gate, not ours, and it sits on a separate axis from our build status on purpose so neither one hides behind the other.

Could you run VIN level native ads through Bidtellect?

No. Rendering a specific vehicle with its price and mileage requires a product catalog fed to the platform, and we generate no such feed for any network. Building the adapter would not close that gap, and it is a separate piece of work.

How would placement filtering be handled?

In the design it travels out with the campaign as a blocklist and the delivery report comes back at placement level so the list can be revised. None of that runs today, and until it does, placement hygiene lives wherever your native buying currently lives.

Requests are counted against the platform they name and the count decides what gets built next. Tell us the trade area you want covered and what you would run first.