Skip to content
Ping/post auctions

Let buyers bid before they ever see the lead.

Ping every eligible buyer at once, collect real bids on partial data, and deliver the full record to whoever pays the most. Multi-step ping, circuit breakers, and a log of every request.

Partial data on the ping
Concurrent fan-out
Multi-step ping
A sold lead showing every bid it received: the winning buyer at $95.48, three buyers outbid, one below the campaign minimum, one rejected by a filter, and one outside its delivery schedule
Two phases

Ask first. Deliver second.

Buyers commit to a price before the lead leaves your hands — and a rejection on the post falls through to the next bid rather than wasting the record.

Ping — buyers bid on partial data

A partial lead record goes out to every eligible buyer at once. Each answers with accept or reject and an optional bid. Bids come back sorted highest first, so the source sees what the lead is worth before the full record moves.

Post — the winner gets the lead

The winning buyer receives the complete record and confirms. The sale is recorded and the postback fires to the traffic source. You decide which fields travel on the ping and which wait for the post.

Rejected on post? Next bidder

A buyer that bids and then declines the full lead does not kill the sale. Datahubb falls through to the next highest bid, so a late rejection costs you a moment, not the lead.

Multi-step ping

Some buyers price a lead in two passes. Let them.

A buyer can be pinged more than once before the post, and a later step can reference what an earlier one returned. Ask them to score the lead, then ask them to bid on their own score.

  • Reference an earlier response with {{$ping_step_1:data.quality_score}}
  • Each step can carry its own price — the last one to return a price wins
  • Per-step URL, body template, headers, and timeout
Ping stepsper buyer
1
Validate
Buyer scores the lead
$12.00
2
Bid
{{$ping_step_1:data.quality_score}}
$15.00
3
Post
Full lead delivered
$15.00

The last step to return a price sets the final price.

Under the hood

Built for the buyer who goes down at 2am

An auction is only as good as its slowest participant. The engine is built so that one of them cannot become everyone’s problem.

Concurrent fan-out

Pings run through a dedicated Go service that fans requests out concurrently over a pooled, HTTP/2 connection, prioritising the endpoints that are healthy. The auction takes as long as the slowest buyer you allow — not the sum of all of them.

One slow buyer cannot stall the room

A circuit breaker watches every endpoint. Three failures inside five minutes and that buyer is skipped until it recovers, so a dead integration degrades quietly instead of holding up every lead behind it.

Every request and response is kept

Each attempt is logged at three levels — the session, each step, and the raw HTTP exchange behind it. When a buyer claims they never got a lead, you can show them their own response.

One-to-one consent

TCPA consent bidding, built in

Flag a lead as consented and the ping changes shape: buyers bid by name, and the consumer decides who is allowed to call them.

Flag a lead as consented and the ping returns named brand bids instead of a single payout
The source picks the brands the consumer actually agreed to — only those buyers get the lead
The consent language and its timestamp travel with the record
The TCPA mapper runs on the final ping step, so it sees the fully enriched lead
FAQ

Frequently asked questions

Two-phase lead selling. In the ping phase a partial lead record goes to eligible buyers, and each returns an accept or reject plus a bid price. In the post phase the full record is delivered to the winning buyer. You control which fields go out on the ping, so buyers only receive the complete lead they actually bought.

A buyer can be pinged more than once before the post. A first step might ask them to validate or score the lead, and a second step asks them to bid on it — and that second step can reference what the first one returned. It is how you work with buyers whose pricing depends on their own scoring, rather than accepting a flat bid.

The last step that returns a price wins. Each step stores its own price, and a step that returns nothing leaves the previous price standing. So a step-1 bid of $12.00 followed by a step-2 bid of $15.00 posts at $15.00.

A circuit breaker trips after three failures in five minutes and that buyer is skipped until it recovers. The auction continues without them. That is deliberate: a broken integration should cost that buyer their leads, not slow down everyone else’s.

Simple accept/reject conditions cover most buyers. For the rest, response mapping turns a raw reply into an outcome, a price, and a rejection reason using rules over the response body, HTTP status, or headers — thirteen operators, matched in priority order. It means you can integrate a buyer whose API you do not control and would not have chosen.

Yes. Every buyer has test ping and test post endpoints, so you can fire a sample lead at their integration and read the raw request and response back before anything real is at stake.

It is the mechanism an auction runs on. Ping/post is how buyers are asked; the routing strategy decides what happens with the answers — Highest Bidder takes the top bid, while Waterfall, Weighted and Advanced tiers use them differently. See lead distribution for how each strategy picks the winner.

Run a real auction on every lead.

Start your 14-day trial. Full platform access. Card required, no charge if you cancel during the trial.