Ping Post Explained: How Real-Time Lead Auctions Work

What ping post actually is

Ping post is a two-call model for selling a lead in real time. On the first call, the partner (the source of the lead) sends partial data to a distribution platform. The platform checks which buyers qualify, collects their bids, and returns a response. On the second call, the partner posts the full lead (name, phone, email, every custom field) to the buyers who won the auction. Two calls, one lead, sold while the consumer is still on the form.

The reason operators moved from plain direct POST to ping and post is economics. With direct POST, the partner picks a buyer, sends the whole lead, and either sells or gets rejected. Price is static. If the buyer rejects, the partner has already revealed PII for nothing. Ping post flips that. The platform asks every buyer at once, in parallel, who wants this lead and at what price. The highest bid wins the exclusive, or the top N bids win in multisell. Pricing is dynamic, rejections are cheap, and the margin on each lead is set by market demand instead of a spreadsheet.

If you have two or more buyers competing for the same lead type, ping post is the model. If you have one buyer on one offer at a negotiated rate, it is overkill. Everything else in this article assumes you are running at least a handful of contracts per offer.

The two calls: ping + post

The ping is a lightweight HTTP request. The partner sends just enough information to let buyers decide if they want the lead, but no PII. A typical ping payload carries: state, zip, age range or age band, vertical-specific qualifiers (coverage type, homeowner yes or no, credit tier, loan amount band), a timestamp, and the campaign posting key. No name, no full date of birth, no phone, no email. The posting key tells the platform which offer and which partner the ping belongs to.

The platform fans the ping out to every active contract on the offer. Each contract runs its filters (geo match, demographic match, any custom field rules), checks the buyer balance, checks the schedule (is the buyer open right now?), checks dedup (have I already bought this consumer inside my dedup window?), and either returns a bid or returns a decline with a reason. Contracts pointed at a real-time bidding endpoint call out to the buyer for a custom price; fixed-price contracts use the number on the contract.

The response back to the partner is the list of winners with their bids and the post URL for each. At this point the partner decides whether to proceed. If the bids clear the partner floor price, the partner makes the second call: the post. The post carries the full lead payload, including every identifying field and any consent metadata (TrustedForm certificate URL, LeadiD, consent language, timestamp, IP). In multisell the post fans out in parallel to every winning buyer. In exclusive there is a single post to the one winner.

Once the post lands, the platform records a leadSale per winner, increments cap counters atomically, charges the buyer according to the winning bid, and pays the partner according to the campaign payout rule. The postingLog and leadDistribution tables hold the full audit trail: every contract that saw the ping, what bid it returned, why it lost (if it lost), and the final disposition per winner.

Why ping post beats direct POST

Dynamic pricing is the headline. A buyer that has hit 80 percent of its daily cap drops its bid. A buyer running a weekend push raises its bid. The platform picks up both signals automatically because pricing is returned on each ping, not set once per month in a spreadsheet. Partners get more margin on high-demand days and buyers stop overpaying when they are oversupplied.

Distribution decisions also move to auction time. On the same offer you can run exclusive for buyers willing to pay premium, multisell for buyers who expect competition, and a hybrid rule that tries exclusive first and falls back to multisell. The offer sets the rule, the auction picks the winners, and no manual routing logic lives in the form.

Buyers with their own scoring models can plug in an RTB endpoint. The platform posts the ping payload to the buyer URL, the buyer returns a custom price, and the platform treats that price like any other bid. Useful when a buyer wants to price on attributes the platform does not evaluate natively, or when pricing depends on external data (inventory, weather, agent availability, whatever).

Capped buyers decline during the ping, so the waterfall stays clean. Dedup runs during the ping too, which means buyers who already bought this consumer never return a bid that has to be thrown away. On direct POST you learn about the cap or the duplicate after you already sent PII. On ping post the platform knows before anyone bids.

Distribution modes: exclusive vs multisell vs hybrid

Exclusive. One buyer wins. The highest qualifying bid takes the lead and the lead cannot be sold again on that offer. Exclusive is how final expense, high-intent mortgage, personal injury legal, and other verticals where the buyer is paying for guaranteed first contact operate. Exclusive prices run two to four times multisell prices because the buyer gets a fresh consumer with no competing outreach.

Multisell. The top N bidders all win, usually three to five. The full lead posts in parallel to every winner. Multisell is the default for auto insurance, Medicare Advantage, home services, solar quote comparison, anywhere the consumer expects quotes from several providers. Price per buyer is lower than exclusive but total revenue per lead is often higher because you are selling the same lead three to five times in the same auction.

Hybrid. The auction tries exclusive first. If any bid clears a configurable price floor, sell exclusive to the top bidder. If no bid clears the floor, fall back to multisell and sell to the top N. Hybrid captures exclusive premiums when the market supports them without leaving leads unsold when it does not.

Timing and latency

Real-time in ping post means the consumer does not notice the pause. On Lead Router, ping evaluation completes in under 100ms on average. Every eligible contract is evaluated in parallel: filter matching, cap check, buyer balance, schedule, dedup. An offer with 30 active contracts takes roughly the same amount of time as an offer with three, because the work fans out instead of queueing up.

End to end, from partner ping to posted lead in the winners inbox, a typical waterfall finishes under 500ms. Network round trips dominate that budget, not the auction itself. If your ping and post adds noticeable time to form submission, the platform is either evaluating contracts sequentially or the buyer RTB endpoints are slow. Both are fixable and neither is inherent to the model.

Common mistakes operators make with ping post

Incrementing caps on the ping instead of the post. If you charge a cap unit when the buyer bids, you burn budget on rejected bids and the buyer hits the cap on leads it never actually bought. Cap counters should increment only on a completed leadSale, not on a winning bid that the partner never posts against.

Rolling cap periods on server local time. Neon runs in UTC. If your buyer thinks their daily cap resets at midnight Eastern, but the platform rolls at midnight UTC, you will oversell in the afternoon and undersell in the morning. Store the tenant timezone and roll cap periods there.

Skipping dedup during the ping. Dedup at post time is too late: you have already spent compute on the auction, already returned bids to the partner, already set buyer expectations. Run dedup inside the contract evaluation so a buyer with a 30-day dedup window never bids twice on the same consumer in 30 days.

When NOT to use ping post

One exclusive buyer on one offer at a pre-negotiated rate. Direct POST is simpler, faster to set up, and there is no auction to run because there is only one bidder. Use ping post when you have competition. Skip it when you do not.

Verticals with heavy consent-certificate requirements can get awkward on some platforms. TrustedForm and LeadiD certificates need to survive the two-call sequence without being dropped or replayed. If your platform does not propagate the certificate URL on the post, the buyer may reject every lead even though the consumer gave consent. Most platforms handle this cleanly; check before you assume.

FAQ

Related reading