Real-Time HTTP Post Delivery

Post leads straight into a buyer's API

Real-time HTTP Post delivery pushes each lead to a buyer's endpoint the instant it's captured or won, formatted exactly the way their system expects. It's the delivery method built for buyers with their own integration - a CRM, a proprietary intake API, or a third-party platform with a posting endpoint - and it's the one to reach for when a buyer hands you field specs instead of an email address.

Shaping the data to fit their system

Few buyers define fields exactly the way you collect them, so HTTP Post campaigns include field-level transformation before anything is sent:

• Field mapping - rename a field on the way out, such as sending "FirstName" as "First_Name".
• Multi-field mapping - send one value into more than one field, such as passing a work phone into both a work phone and an employer phone field.
• Split fields - break a single value into several, such as splitting a phone number into area code, exchange, and line.
• Format data - reformat values on delivery, such as converting a 10-digit number into a dashed phone format, or reformatting a date.
• Custom rules - remap values with a simple comma-separated rule, such as converting "Male/Female" to "M/F".
• Data options - for multi-value fields, send either the raw value or its label, such as a state code or the full state name.

Connection details

Connect via POST, GET, or PUT; fully URL-encode the request with one click; choose whether blank fields are sent or omitted; and attach static post parameters - usernames, API keys, campaign IDs - to every delivery. Posting headers can also be customized, and lead tokens let you pass Lead Capsule's own lead ID, the vendor ID, the lead's create timestamp, or the current time along with the data.

Knowing whether a lead was accepted

Lead Capsule reads the buyer's response and marks each lead accepted or rejected based on a static or dynamic (regular-expression) match, so you don't have to guess at outcomes. It can also capture data back from that response: the buyer's own lead ID, a redirect URL to pass on to your source or vendor (with a configurable expiration), a dynamic sale price, or any other custom value the buyer returns. A configurable timeout marks a lead rejected if no response arrives in time.

Delivery controls

• Delivery caps - per-minute, hourly, daily, weekly, or monthly limits, for both post and prepaid orders.
• Exclusivity - control how long a lead stays exclusive and how many times it can be resold.
• Advanced filtering - restrict delivery to leads matching any field definition, down to a specific zip range or age bracket.
• Scheduling - deliver only within a buyer's preferred daily or overnight window.
• Lead verification - validate a lead in real time before it's posted.
• Auto responders - notify the applicant automatically once their lead is posted.

Delivering aged leads by HTTP Post

The same campaigns can push aged inventory instead of fresh leads, with controls to throttle delivery so leads trickle in rather than arrive all at once, cap the batch size per execution, restrict by minimum or maximum lead age, and limit delivery to leads under a certain resale count.

Where this fits with ping/post

HTTP Post is also the transport most ping/post and PingPickPost campaigns post the winning lead over, once a buyer has bid on or been selected for a partial-lead ping.