> ## Documentation Index
> Fetch the complete documentation index at: https://docs.usejuiced.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Ping-Post

> The ping/post workflow for real-time lead validation and delivery to partners.

Ping-post is a two-step process for selling leads in real time. First, a **ping** sends partial lead data to determine pricing and acceptance. Then, a **post** delivers the full lead data once a buyer is confirmed.

This workflow lets you validate leads and get competitive bids before committing to a sale—maximizing revenue while ensuring leads only go where they're wanted.

## How it works

1. **Ping phase**: Your source sends partial lead data (typically just enough to identify the lead type and location). Juiced auctions this data to your customers, collecting bids in real time.

2. **Post phase**: Once a winning bid is determined, your source sends the complete lead data. The lead is assigned to the winning customer, funds are transferred, and everyone's happy.

The ping contains minimal information to protect the lead's value until a buyer commits. The post delivers everything needed to contact and convert the lead.

## Partner integrations

Partners are external systems that receive your leads. When you configure a partner integration, you set up both ping and post configurations to match their API requirements.

### Request mapping

Each partner has their own field names and payload structure. Request mapping lets you transform Juiced's lead data into whatever format your partner expects.

Use merge fields in double curly braces to insert lead data:

```json theme={null}
{
  "firstName": "{{ first_name }}",
  "lastName": "{{ last_name }}",
  "email": "{{ email }}",
  "phone": "{{ phone }}"
}
```

The mapping field picker shows all available fields for the lead category, with sample values to help you identify the right data.

### Using ping response data in posts

Some partners return data in their ping response that must be included in the subsequent post request—things like session IDs, tracking tokens, or campaign identifiers.

When configuring a post request mapping, you can reference fields from the ping response using the `response.` namespace:

```json theme={null}
{
  "ping_id": "{{ response.ping_uuid }}",
  "campaign": "{{ response.metadata.campaign_id }}",
  "first_name": "{{ first_name }}",
  "last_name": "{{ last_name }}"
}
```

The mapping field picker displays a **Ping Response** section showing available fields from the partner's most recent ping response. These fields appear with their actual values from the last ping, making it easy to identify what data is available.

<Note>
  Ping response fields are only available when configuring **post** requests. They won't appear in ping request mappings since no response exists yet at that point.
</Note>

<Tip>
  If you don't see ping response fields in the picker, the partner may not have received any pings yet, or their ping responses may not include any data. Try sending a test ping first.
</Tip>

### Offer penalty percentage

Sometimes you want to give certain partners a competitive disadvantage without changing what they actually pay. The **offer penalty percentage** does exactly this—it reduces a partner's offer score without affecting the charged amount.

For example, if a partner submits a \$100 offer and has a 25% penalty:

* Their **offer score** becomes \$75 (used for ranking)
* Their **charged amount** stays \$100 (what they actually pay if they win)

This is useful when:

* A partner has lower lead quality or conversion rates
* You want to favor other partners without explicitly blocking anyone
* You're managing partner relationships while maintaining pricing transparency

To set a penalty, enter a percentage (0-100) in the **Offer Penalty (%)** field on the partner form. Leave it empty for no penalty.

<Note>
  The penalty percentage is snapshotted on each offer, so changing a partner's penalty only affects future offers—not ones already in the system.
</Note>

## Offer scoring

When multiple partners respond to a ping, their offers are ranked by score. The highest score wins. By default, the score equals the offer amount, but penalties can reduce this:

| Partner   | Offer Amount | Penalty | Offer Score | Winner? |
| --------- | ------------ | ------- | ----------- | ------- |
| Partner A | \$100        | 0%      | \$100       | Yes     |
| Partner B | \$110        | 25%     | \$82.50     | No      |
| Partner C | \$90         | 0%      | \$90        | No      |

In this example, Partner A wins even though Partner B offered more money—because Partner B's penalty brought their score below Partner A's.