Offer Campaign APIs
Create Source Post API
The API URL serves as the endpoint where the traffic source submits lead data. This URL must be installed and used by the source sending the data to ensure it’s received properly by Pingtree. Find detailed documentation here. Use Generate Specs feature to get the api specification for this endpoint.
POST
cURL
Overview
The Source Post API is the second step in a two-call ping-post flow. After a successful ping returns aping_accept status and a transaction_id, call this endpoint to submit the full lead — including all PII — and finalise the distribution to the matched buyer(s).
This endpoint must only be called after a successful ping. The transaction_id from the ping response is required to link the two calls together.
Endpoint
{source-unique-id} with the linkUniqueId for your source, found in your posting specification under the Post API section.
Authentication
Include the post-specific API token in theAuthorization header:
Request Parameters
Path Parameters
| Parameter | Type | Required | Description |
|---|---|---|---|
source-unique-id | string | Yes | Link unique ID for this source-campaign pairing |
Body Parameters (JSON)
| Parameter | Type | Required | Description |
|---|---|---|---|
transaction_id | string | Yes | The transaction ID returned by the Ping API |
first_name | string | Conditional | Consumer’s first name |
last_name | string | Conditional | Consumer’s last name |
email | string | Conditional | Valid email address |
mobile | string | Conditional | 10-digit phone number (digits only) |
address | string | Conditional | Street address |
city | string | Conditional | City name |
state | string | Conditional | 2-letter state code |
zip_code | string | Conditional | 5-digit ZIP code |
date_of_birth | string | No | YYYY-MM-DD format |
sub1 – sub5 | string | No | Publisher sub-tracking parameters |
adv1 – adv5 | string | No | Advertiser sub-parameters |
jornaya | string | No | Jornaya LeadiD token |
xxTrustedFormCertUrl | string | No | TrustedForm certificate URL |
tcpa_consent | string | No | TCPA consent value |
tcpa_consent_date | string | No | TCPA consent timestamp |
Example Request
Example Responses
Success — Lead Sold
Success — Lead Unsold
Error — Missing Transaction ID
Error — Invalid Field
Status Codes
| HTTP Code | Lead Status | Description |
|---|---|---|
| 201 | accepted | Lead distributed to buyer(s) matched during ping |
| 201 | unsold | Lead recorded but not distributed (buyer retracted, cap, etc.) |
| 400 | missingField | Required field (including transaction_id) is absent |
| 400 | invalidField | Field failed format validation |
| 400 | rejected | Post rejected (ping expired, invalid transaction_id, campaign rules) |
| 401 | rejected | Invalid or missing post token |
| 405 | rejected | HTTP method not allowed |
| 500 | rejected | Internal server error |
Tips
- Always use the ping’s
transaction_id. The post call is linked to the ping via this ID. Submitting a new or mismatched ID will result in a rejection. - Post promptly after ping. Ping acceptances have a time-to-live window. If the consumer takes too long to fill in the form, the bid may expire and the post could be rejected or unsold.
- Include the same custom fields. Buyer evaluation during ping used the custom fields you sent. Include them again in the post for consistency and to avoid validation errors.
- Redirect URL: Store
redirect_urlfrom the post response and redirect the consumer immediately to complete the buyer journey. - Do not reuse tokens across steps. The ping token and post token are different credentials. Using the wrong token returns a 401 error.
cURL