How to Use System Fields in Lead Prosper Integrations

To better assist you with routing your leads, Lead Prosper comes prepared with a few system fields that you can implement in your payload that is sent to your buyers, or utilize them in webhooks.

Like the campaign fields, these shortcodes can be added to:

  • real-time and webhook payload builder, for both HTTP or Email delivery
  • direct post and ping/post URLs
  • direct post and ping/post headers
  • most can be used in campaign triggers and buyer webhooks

Available System Shortcodes

  • {{lp_ping_response}}

    returns the full response body of a PING request that was sent to a buyer. Can only be used in PING/POST setups, and only in the POST payload or buyer webhooks. Note: always sent as JSON encoded.

  • {{lp_ping_response:KEY}}

    extracts a specific KEY from the response body of a PING request that was sent to a buyer. To read more about how to set the correct KEY, please read this article regarding response parsing.  Can only be used in PING/POST setups, and only in the POST payload or buyer webhooks.

  • {{lp_post_response}}

    returns the full response body of a POST request that was sent to a buyer. Can only be used in buyer webhooks. Note: always sent as JSON encoded.

  • {{lp_post_response:KEY}}

    extracts a specific KEY from the response body of a POST request that was sent to a buyer. To read more about how to set the correct KEY, please read this article regarding response parsing.  Can only be used in buyer webhooks.

  • {{lp_buyer_response:BUYER_ID,WHERE_FROM,KEY}}

    returns the raw response a buyer returned during a ping or post — the full body, or a specific value if you provide a KEY. Can only be used in campaign triggers. See Buyer Response below for parameters and encoding details.

  • {{lp_lead_date}}

    returns the date at which the system received a lead, in the user timezone. Very useful in PING/POST setups, where the date has to be the same in both ping and post. Webhooks and campaign triggers can also benefit from this date. Example output: 2020-01-15 16:34:56. Can be transformed to another format using payload field transformers. Timezone is always the user timezone and cannot be changed. Use lp_lead_date_utc if you need to generate a date in a specific timezone.

  • {{lp_lead_date_utc}}

    returns the date at which the system received a lead, in the UTC/GMT timezone. Very useful in PING/POST setups, where the date has to be the same in both ping and post. Webhooks and campaign triggers can also benefit from this date. Example output: 2020-01-15 16:34:56. Can be transformed to another format or another timezone using payload field transformers.

  • {{lp_current_date}}

    returns the current date, in the user timezone. This is different from {{lp_lead_date}} , as it does not retain the date between requests related to a specific lead. Example output: 2020-01-15 16:34:56. Can be transformed to another format or another timezone using payload field transformers.

  • {{lp_current_timestamp}}

    returns the current UTC timestamp. Example output: 1582315643

  • {{lp_campaign_id}}

    the campaign id

  • {{lp_supplier_id}}

    the supplier id

  • {{lp_supplier_name}}

    the supplier nickname or client company name

  • {{lp_supplier_client_id}}

    the supplier Client ID

  • {{lp_supplier_client_name}}

    the supplier Client name (first + last)

  • {{lp_supplier_client_company}}

    the supplier Client company

  • {{lp_supplier_client_email}}

    the supplier Client email

  • {{lp_supplier_client_phone}}

    the supplier Client phone number

  • {{lp_buyer_id}}

    the buyer id

  • {{lp_buyer_name}}

    the buyer nickname or client company name

  • {{lp_buyer_client_id}}

    the buyer Client ID

  • {{lp_buyer_client_name}}

    the buyer Client name (first + last)

  • {{lp_buyer_client_company}}

    the buyer Client company

  • {{lp_buyer_client_email}}

    the buyer Client email

  • {{lp_buyer_client_phone}}

    the buyer Client phone number

  • {{lp_buyer_sell_price}}

    the individual buyer sell price (if the buyer accepted the lead). In a shared campaign, this will reference a specific buyer price and can be different from the lp_lead_sell_price. Default is 0. Can only be used in buyer webhooks/campaign triggers.

  • {{lp_request_uuid}}

    the internal UUID that Lead Prosper generates. This is the same that is returned back to your supplier in the response and also displayed in the logs

  • {{lp_lead_id}}

    the generated Lead Prosper lead id

  • {{lp_lead_status}}

    the lead status: ACCEPTED, DUPLICATED or ERROR

  • {{lp_lead_error_message}}

    the lead error message. Empty for success. Can only be used in buyer webhooks/campaign triggers.

  • {{lp_lead_buy_price}}

    the final total buy price of a lead. In a shared Ping/Post Exchange, this will be the price sum of all bids that the supplier accepted to sell to. Default is 0. Otherwise, it will be the price you defined or the price that was calculated based on your pricing rules. Can only be used in buyer webhooks/campaign triggers.

  • {{lp_lead_sell_price}}

    the final total sell price of a lead across all your buyers. In a shared multi buyer campaign, this will be the price sum of all buyers that accepted the lead. Default is 0. Can only be used in buyer webhooks/campaign triggers.

Buyer Response — {{lp_buyer_response}}

The {{lp_buyer_response}}  shortcode exposes the raw HTTP response a buyer returned during a ping or post. You can return the entire response body or extract a single value from it — useful for forwarding buyer-returned data such as confirmation numbers, real-time prices, redirect URLs, or third-party IDs to webhooks, emails, or Google Sheets actions.

Where it can be used: this shortcode works only inside Campaign Triggers. It will not resolve in buyer payloads, buyer webhooks, computed fields, or API filters. The reason is timing — a campaign trigger is the first point in the lead lifecycle where the buyer's response is guaranteed to exist. (A buyer webhook, by contrast, also fires for buyers that were filtered out and never posted to, so the response data is unreliable there.)

The format of this shortcode is:

{{lp_buyer_response:BUYER_ID,WHERE_FROM,KEY}}

  • BUYER_ID — the ID number of the buyer you are referencing (for example, 1051 ).
  • WHERE_FROM — either ping  or post . Ping/Post buyers accept either; Direct Post buyers only accept post .
  • KEY — optional. A path to extract a specific value from the response body. Leave it blank to return the entire body. Use the Response Parser tool to find the correct key.

Return values and encoding

To keep complex responses or special characters from breaking your JSON, XML, or form payloads, the shortcode applies Base64 encoding in some cases:

  • No KEY provided — returns the entire response body, Base64-encoded. Decode it on the receiving end.
  • KEY provided, simple scalar value (string, number, or boolean) — returns the raw, unencoded value.
  • KEY provided, object/array/XML subtree — returns a Base64-encoded JSON string.

Because non-string values are encoded automatically, you do not need to add ||encode:base64  yourself.

The shortcode returns an empty string when the key is not found, when the buyer didn't run or reach that step, when the buyer isn't part of the trigger, or when you request ping  on a Direct Post buyer.

Examples

  • {{lp_buyer_response:1051,post}}  — the full post response body from buyer 1051, Base64-encoded.
  • {{lp_buyer_response:1051,post,status}}  — just the status  value from buyer 1051's post response.
  • Reference multiple buyers in one trigger by adding a field per buyer, for example (form-style payload): buyer_1051_response={{lp_buyer_response:1051,post}}&buyer_1099_response={{lp_buyer_response:1099,post}}

You can chain payload field transformers to this shortcode just like a campaign field. For example, {{lp_buyer_response:1051,post,status||lower_case}}  lower-cases the extracted status value.

Tip: in Campaign Triggers, {{lp_buyer_id}}  returns a comma-separated list of every buyer the trigger matched, not a single ID — so reference each buyer's ID explicitly rather than expecting one generic entry to cover all buyers.

Note for Google Sheets triggers: type the shortcode directly into the field rather than using the "+" selector icon.

To handle the One-to-One requirements, we created a special shortcode that can be used in the POST body for these type of buyers: {{lp_consent_buyer_bids}}. This special shortcode will match the bid ids sent by the supplier in the POST request with the actual bid IDs or names from the buyer's PING response.

The format of this shortcode is: {{lp_consent_buyer_bids:VALUE TO EXTRACT, OUTPUT TYPE, OUTPUT PROPERTY}}. We know this looks intimidating, but it will make more sense soon. Let's break down the options:

  • VALUE TO EXTRACT: can only be set to id or name. Some buyers require to send the TCPA or Brand Name in the POST instead of a unique ID, so this setting will allow to specify what to send. If it's set to id, we will send whatever Bid ID Key is configured in the PING configuration. If it's set to name, we will send the TCPA Name that we extracted from the PING response.

    Example Ping Setup
  • OUTPUT TYPE: can be set to: csv (default), array, xml. CSV will take the values extracted and simply separate them by comma. ARRAY can be used with JSON buyers, where the values extracted must be sent as an array. XML can be used for XML buyers, where the output usually needs to be very specific.
  • OUTPUT PROPERTY: this optional setting is used mostly with XML buyers, but also common with some JSON buyers. This will tell the system how to send back the values extracted from the PING. This setting allows you to use dots to create a complex output schema. Check the examples bellow for a more in depth explanation.

Examples

  • {{lp_consent_buyer_bids:id}} will send to the buyer a comma separated list of IDs extracted from the PING response. Ex: unique_id1,unique_id2. If used with name as a value {{lp_consent_buyer_bids:name}}, it will send a comma separated list of TCPA Names. Ex: Legal Name1,Company 2
  • {{lp_consent_buyer_bids:id,csv}} or {{lp_consent_buyer_bids:name,csv}} is the same as previous.
  • {{lp_consent_buyer_bids:id,array}} will output to the buyer an array of unique IDs extracted from the PING. Most common with JSON buyers. Can be used with the name instead of the id to send an array of TCPA Names. Ex output:
[
  "3cffeadd-0dd9-4cee-b8de-a39b0d13d3a3",
  "b144852d-326c-49e6-a0d3-1caaf5edf827",
  "d5bab2ce-33d2-4a66-b4c9-d9b2cab2a968"
]
  • {{lp_consent_buyer_bids:name,array,BrandName}} will output an array of objects that contain BrandName as the property and the extracted TCPA name as the value.
[
  {"BrandName": "Company 1"},
  {"BrandName": "Legal Name 2"}
]
  • {{lp_consent_buyer_bids:id,array,Brand.ID}} will output an array of objects that contain Brand objects with ID as property name and the extracted unique IDs as the value.
[
  {
    "Brand": {
      "ID": "3cffeadd-0dd9-4cee-b8de-a39b0d13d3a3"
    }
  },
  {
    "Brand": {
      "ID": "d5bab2ce-33d2-4a66-b4c9-d9b2cab2a968"
    }
  }
]
  • {{lp_consent_buyer_bids:name,xml,BrandName}} will output an XML string that contains BrandName elements
<BrandName>Company A</BrandName>
<BrandName>Company B</BrandName>
  • {{lp_consent_buyer_bids:id,xml,Bid.ID}} will output an XML string that contains Bid elements with an ID property
<Bid><ID>3cffeadd-0dd9-4cee-b8de-a39b0d13d3a3</ID></Bid>
<Bid><ID>d5bab2ce-33d2-4a66-b4c9-d9b2cab2a968</ID></Bid>

IMPORTANT: when using array as the output, please make sure not to include the brackets in the body configuration.

Correct example

Buyer payload configuration

{
  ...
  "bids": "{{lp_consent_buyer_bids:id,array}}"
  ...
}

Will result in:

{
  ...
  "bids": [
    "3cffeadd-0dd9-4cee-b8de-a39b0d13d3a3",
    "d5bab2ce-33d2-4a66-b4c9-d9b2cab2a968"
  ]
  ...
}

Incorrect example

{
  ...
  "bids": [
    "{{lp_consent_buyer_bids:id,array,ID}}"
  ]
  ...
}
Did this answer your question? Thanks for the feedback There was a problem submitting your feedback. Please try again later.

Related Articles