Ping/post integration for lead buyers

What a ping contains

A ping carries partial, non-identifying data: the vertical and sub-type (for example roof replacement or a car accident with injury), the state and ZIP code, and the consumer's answers to the qualifying questions for that vertical. It never carries full contact details. No name, phone number, email address or street address leaves Summit Leads until a buyer has won the lead.

How your system responds

For each ping, your endpoint returns either a bid or a decline. A bid is the amount you will pay if you win the lead; a decline tells us to move on. Your reply must arrive within the response window agreed at setup. A reply that arrives late, or an endpoint that does not answer, is treated as a decline for that lead, so a slow endpoint costs you volume.

What the post contains

The winning buyer receives the post. It contains the full contact data (name, phone, email and, where the vertical needs it, address), the lead fields collected for the vertical, and the consent record. The consent record includes the opt-in language the consumer saw, the timestamp of submission, the IP address and the page URL where consent was given. Store it with the lead: it is what you, or your client, will rely on if a contact is ever questioned. Our TCPA compliance guide covers what a usable record looks like.

The exact field specification (field names, formats, required and optional fields per vertical) is shared during onboarding, so your developer can map it before test traffic starts.

Example ping and post (illustrative)

Illustrative only. Field names, formats and timing are set in the specification shared during onboarding. The blocks below show the shape of each message with placeholder values in capitals. They contain no real consumer data and no real bid values.

{
  "ping_id": "PING_ID",
  "vertical": "VERTICAL",
  "sub_type": "SUB_TYPE",
  "state": "STATE",
  "zip": "ZIP_CODE",
  "answers": {
    "qualifying_question_1": "ANSWER_1",
    "qualifying_question_2": "ANSWER_2",
    "qualifying_question_3": "ANSWER_3"
  }
}

{
  "ping_id": "PING_ID",
  "accept": true,
  "bid": "BID_AMOUNT"
}

{
  "ping_id": "PING_ID",
  "first_name": "FIRST_NAME",
  "last_name": "LAST_NAME",
  "phone": "PHONE",
  "email": "EMAIL",
  "address": "STREET_ADDRESS",
  "state": "STATE",
  "zip": "ZIP_CODE",
  "answers": {
    "qualifying_question_1": "ANSWER_1",
    "qualifying_question_2": "ANSWER_2",
    "qualifying_question_3": "ANSWER_3"
  },
  "consent": {
    "opt_in_text": "OPT_IN_TEXT_SHOWN_TO_CONSUMER",
    "timestamp": "SUBMISSION_TIMESTAMP",
    "ip_address": "IP_ADDRESS",
    "page_url": "PAGE_URL"
  }
}

Testing before going live

Before live traffic, we send test leads to your endpoint so your developer can confirm that pings are parsed, bids and declines come back in the agreed format, and posts land in your system with every field mapped. Once test leads pass, you start on a small live volume so your operations team can check contact rates and quality before caps are raised. Most partners go live within 24-72 hours after setup.

Returns

Return terms are discussed on the onboarding call and agreed before going live. The terms set out which reasons qualify and how a return is submitted, so both sides work from the same rules.

What to send Summit Leads to start

• Your ping and post endpoint URLs (or one URL, if your system handles both steps)
• Your field mapping: the names and formats your system expects for each lead field
• Filters per campaign: vertical and sub-type, states or ZIP codes, and any other criteria
• Daily caps per campaign, and any hourly or day-of-week delivery limits
• Whether you want ping/post, direct post, or batch delivery
• A contact for technical questions during integration and testing

Email these to team@summitleads.ai. Buyers setting up supply for the first time can read how to become a partner first.