Run Paved from Your Dealership CRM

A marketplace of booked newsletter sponsorships across independent publishers, and why booking is not the same as buying an auction.

Paved is a marketplace that sits between advertisers and independent newsletter publishers. A buyer browses titles, reads the audience description and the historical performance a publisher reports, and books a sponsorship into a named send at an agreed price. The marketplace handles the discovery, the paperwork and the money, and the publisher writes the placement into their issue.

The difference from a self serve ad network is that this is a booking rather than a bid. You are not entering an auction that fills whenever budget and audience align. You are reserving a slot in a particular issue on a particular date, at a price agreed before anything runs. Publishers span the whole range from general business writing to narrow enthusiast titles, which is where an automotive advertiser tends to find the interesting inventory.

For a store the useful mental picture is buying a page in a specialist magazine, with the difference that the audience is smaller, more attentive, and reachable in single figures of days rather than a quarterly print cycle.

The case is reach into audiences that social targeting cannot describe. A newsletter for people who restore older trucks, or one written for a specific metropolitan area's small business owners, gathers exactly the people a store would love to talk to and gathers them by shared interest rather than by inferred behaviour. Paved makes those titles findable in one place, with the publisher's own numbers in front of you before you commit, and with a marketplace between you and a stranger asking for money.

The honest objection is that a booking is a commitment. Once a sponsorship is reserved you cannot throttle it, shift it to a better performing title mid week, or turn it off when the response rate disappoints. Everything that makes auction buying forgiving is absent. If the creative is wrong, you find out after the send and the money is spent. That is a real difference in risk from every biddable channel in this catalogue, including a continuously delivered one like streaming audio.

The second objection is measurement of the buy itself. Pricing is generally per thousand against a list size and an open rate the publisher reports. Those numbers are theirs, not an ad server's, and the marketplace reviews publishers rather than auditing every send. Treat a first booking with a new title as a test whose main output is knowing whether the numbers hold up.

Not started. The published test for that status is that no adapter file exists in the LeadLocate ad gateway for this platform, and none does. No authorization URL, no wire-up checklist, no partially written token exchange. A dealer can hold us to that sentence, which is why it is written that way.

Access class is PARTNER, the vendor's gate rather than ours. Programmatic credentials require an application the vendor reviews before issuing them. That review runs on somebody else's calendar and no amount of engineering on our side shortens it, which is exactly why status and access are published on two separate axes instead of blended into one comfortable sentence.

There is a second reason this one sits where it does, and it is not about difficulty. A marketplace of booked placements does not map cleanly onto software that deploys and pauses campaigns. The valuable automation here would be discovery, booking calendars and reconciliation, none of which is what our gateway was built to do. An adapter would either be honest and narrow, or wide and misleading. That decision has not been made because nobody has yet asked for it.

A design sketch, not a description. Nothing here runs and no code path in the CRM reaches this vendor.

The row that surprises people is the second one. Almost everything coming back is a booking record rather than live delivery telemetry, because the placement lives inside somebody else's email rather than inside an ad server you can query.

Any platform we add answers the same contract, and reading this one against it is instructive.

Inside LeadLocate a single library defines 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 rather than an open ended project, and why turning one on does not disturb the network already running.

Now hold a booked sponsorship against those seven. Deploy becomes reserve. Pause has almost no meaning once an issue has been sent, and resume has none at all. Return spend becomes reconcile an invoice. Four of the seven survive intact and three change character, which is a genuine argument for a narrow adapter that covers discovery and booking rather than a full one pretending the calendar is an auction. The same tension appears on every marketplace entry in this directory.

What would carry over untouched is the plumbing. Credentials encrypted with AES-256-GCM before storage. 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. Objects that record which credentials created them and re-resolve those same credentials later, so a disconnected account never orphans a live booking.

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 application to file with anybody.

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. Disconnect whenever you like and delivery falls back to the managed path.

Neither path reaches this marketplace yet. A store that wants the inventory today opens an account with the vendor directly, books the sponsorship itself, points the link at a landing page and works the responses in the CRM by hand. That is not an integration and this page will not dress it up as one, but it is an honest answer to what a dealer is usually really asking, which is whether they can run the channel at all.

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

The order is decision, application, adapter, proof. First a decision about how much of a booking marketplace the gateway should model, because a narrow honest adapter and a wide misleading one cost about the same to write. Then the vendor application and its review. Then the adapter against whichever operations were chosen. Then a verification call against a real account before money moves.

Measurement follows the calendar rather than the budget. A booking sits idle until its send date, produces its whole result within a day of that send, and then goes quiet. You cannot read a trend from one placement, so a serious test means several titles across several weeks, priced and planned up front. That is a slower feedback loop than any auction based channel in this catalogue and it should be budgeted as a test rather than as a monthly line.

Everything after the click belongs to you. There is no form inside a newsletter, so your landing page and the speed of the first callback decide the result. A cheap click wasted by a slow response is the commonest way this channel gets written off, and it has nothing to do with the media. None of that is a promise about volume, which nobody can make honestly.

Short list, stated flatly, because a marketplace page is where vague language does the most damage.

No booking has ever been made here from the CRM. There is no code that could make one. Any vendor page showing this logo beside a connection claim is showing you a logo.

No form submission comes back from this channel, and our form retrieval is built for one network anyway. The only network where a submitted form reaches us through a signature checked webhook is the single platform carrying the connected status.

We do not emit a vehicle catalog. Nothing in our stack generates a product feed for any advertising system, so a sponsorship that renders your live inventory is not something we could produce.

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. Attribution is your destination link and your own analytics.

We do not export a hashed audience, and a dealer cannot push, activate, pause or read spend on any network without our team. Both are true across the gateway, not just here.

Say so with your store attached, and say which titles you would book, because on this channel the title choice is the whole strategy. 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.

Be honest with yourself about what automation would buy here. Booking a sponsorship is a few minutes of a person's time, so the case for building this is not efficiency. It is reconciliation: knowing which booking produced which response, across a dozen titles and a quarter of sends, without a spreadsheet that somebody has to keep. That is a real problem and it is worth naming in the request, because it is the version of this that justifies engineering.

Meanwhile the managed path runs today and waits on none of it. Pricing is on the pricing page and does not change based on which networks you turn on.

Does LeadLocate integrate with Paved 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 Paved account?

Not through the CRM, because there is nothing to attach it to. Using it directly is entirely reasonable here: book the sponsorship yourself, point the link at a landing page you control, and work the responses in the CRM like any other inbound.

What happens if I request Paved?

It is recorded against this platform specifically and counted, and the tally decides build order. A request naming the reconciliation problem, rather than asking for booking automation, is the version that makes the engineering case.

Can I pause a sponsorship that is not working?

Not in any meaningful sense. A booking reserves a slot in a named issue at an agreed price, so once that issue is sent the money is spent. That risk belongs to the buying model rather than to any missing software, and no integration would change it.

How reliable are the audience numbers?

They are the publisher's own reported list size and open rate, presented by a marketplace that reviews its publishers rather than auditing every send. Treat a first booking with a new title as a test of whether the numbers hold, and price it accordingly.

Why does the access class say PARTNER?

Because programmatic credentials require an application the vendor reviews before issuing them. That is the vendor's gate rather than ours, and it is kept on its own axis so that our build status and their approval never get blurred into one sentence.

Requests are counted against the platform they name. If you are already booking sponsorships and cannot tell which one produced which response, say so and we will put a number against it.