Ping/post lead distribution, explained without the jargon

Ping/post splits lead submission into two steps. A ping asks whether a lead has an eligible destination using a limited set of information. A post then submits the full record using the result of that first check.

See BESO in action. The network overview1:34

Ping first, post second

Think of the ping as checking whether the network can accept an opportunity before completing the handoff. The response might include acceptance information, a reference identifier, and an expiration. The publisher then posts the full lead according to the campaign’s contract.

The exact fields and commercial meaning vary by platform. A ping is not automatically a completed sale, and not every ping/post system is an auction. Some check eligibility and reserve inventory; others gather bids from multiple buyers.

Check eligibility first, then deliver the full lead using its reference.

How this differs from direct post

Direct post submits the complete lead in one request. That can be suitable when the destination and acceptance rules are already established. Ping/post adds a preliminary decision, which can be useful when availability or eligibility needs checking before the full handoff.

Neither design removes the need for validation, authentication, duplicate handling, or clear error responses. A fast rejection with a useful reason is usually more actionable than a generic success message that hides a delivery failure.

Understand BESO’s inbound flow

BESO’s inbound lead endpoints support direct post and ping/post. In its current inbound lead contract, a ping checks eligible prepaid buyer capacity and reserves it for a limited period. The full post references the ping before that reservation expires.

Use the campaign’s generated endpoint details and current posting specification when implementing an integration. Do not assume that another vendor’s request format, field names, or bidding behavior will work unchanged. External buyer auctions and partner-specific adapters require their own verified implementation.

Test the failure paths as well as acceptance

  • A valid lead with an eligible buyer.
  • No eligible buyers or available inventory.
  • A post after its ping reservation expires.
  • A missing or invalid required field.
  • A network timeout followed by a retry.
  • A duplicate submission of the same lead.

An idempotency key lets the receiving system recognize a retry of the same operation. Reuse it for that retry, not for a different lead. A timeout means the sender does not know the result; it does not prove the receiving system did nothing.

Keep request references and response results in your integration logs without exposing credentials or unnecessary personal data. That gives both sides a concrete record when a handoff needs investigation.

Written by the BESO Network editorial teamExplore all guides

Your network.
Your next chapter.

Bring calls, leads, and appointments together under your brand.

Explore BESO with us