The Tracking API is a server-to-server method that allows PalDock to repeatedly query an advertiser’s server about a conversion until the desired result is reached without relying on browser pixels or cookies. Tracking API is basically a Connection Creator with all its features, but customized for tracking.
Tracking API can be used by:
- PalDock admins – to call the advertiser’s API and retrieve information about the conversion status.
- Affiliate partners – to forward conversion information into their own systems.
When creating a Tracking API, you can set conditions that determine whether it will run. These conditions include:
- Source – All, Link, Iframe, API
- Conversion type – All, Lead, Send, Prospect, Sale, Custom
- Affiliate – All or specific
- Advertiser – All or specific
- Integration – All or specific
- Channel – All or specific
- Included Offers – All or specific
- Excluded Offers – All or specific
- Result – Not chosen, All or specific
When a condition is set, the Tracking API will only fire if the conversion matches that condition.
For example, if you set a condition on result, only conversions with the result (transactions) will be sent. If no condition is set, all conversions will be sent, including those without a payout.
Tracking APIs are listed in the Tracking API table, with country categorization inherited from the Offer. If no or multiple Offers are selected, the global country is applied and the category remains blank.
Trigger
Apart from conditions, each Tracking API also has a trigger that defines when it should fire. Available triggers are:
- ALL – (default) – fires on any change to a transaction (create or update)
- Created – fires only when a new transaction is created
- Updated – fires only when an existing transaction is updated
👉 In 90% of cases, you will use the All trigger, which is the default, and then limit it with conditions.
The other triggers exist for specific use cases.
How triggers behave in practice
- A new conversion (click) → triggers 1, 2
- A new conversion (sale) without commission → triggers 1, 2
- A conversion (lead) created via iframe and immediately updated with cookie data via pixel → triggers 1, 2, 3
- The update is a separate event, and its trigger fires independently.
- A conversion (lead) created via iframe and immediately updated with cookie data via pixel, which created a transaction → triggers 1, 2, 3
- Same as above
- A new conversion (sale) which created transaction → triggers 1, 2
- A conversion (sale) updated with a value change → triggers 1, 3
- The same conversion (sale) updated again, this time with a result change → triggers 1, 3
⚡ Tip: If you are not sure which trigger to use, stick with the Transaction (all) trigger and filter by conditions (such as result or commission).
Some examples:
- Want to trigger it only for approved transactions? Set the trigger to ALL and add the condition result = Approved.
- Want to trigger it only for approved transactions that contain cookie parameters? Set the trigger to Update and add the filter result = Approved.
Affiliate postback
If a Tracking API is created by an affiliate, it will appear in their Affiliate Postback section. However, if an admin creates a Tracking API with the condition affiliate = specific affiliate, it will not be listed there, and only the Admin will see it.
Timeout and Limits
The Tracking API supports a configurable timeout for each request (default is 40 seconds) and allows you to define how many times a postback can be retried. This is useful when the initial response indicates that the result is still pending, and you need to check again later for the final result. Currently, the maximum limit is 30 retries.
Special cases
When a pingtree includes multiple channels from the same advertiser, but each requires a different authorization token, the system cannot reuse a single postback across them. In this case, you need to duplicate the postbacks for each channel and assign the correct API token provided by the advertiser. This ensures that requests are authenticated properly for every channel.
Conversion Updates: Advertiser vs. Affiliate Flow
PalDock can both receive conversion updates from advertisers and send updates to affiliates. If both are active, they run at the same time, which usually means affiliates get notified twice (first for creating a pending transaction, and later for updating the result).
How it works with the “All” trigger:
- Conversion creation
- When a conversion is created, the affiliate immediately receives an info.
- If the conversion creates a transaction, the result is usually pending.
- If the transaction is created with the AutoApprove feature enabled, the affiliate will immediately receive the result Approved; an update is sent to the affiliate too and immediately.
- Updates from the advertiser
- When the advertiser later provides more details (e.g. approved, rejected, payout amount), PalDock instantly forwards these updates.
- Affiliates may therefore receive multiple requests per conversion, although in most cases, it is only two (create + update).
- Multiple commissions
- If multiple commissions apply, each update is sent separately. Affiliates must aggregate them on their side.
- Filtering
- If an affiliate in Affiliate Postback does not want to receive pending conversions, this can be filtered out by setting a condition on the result.
Optional delay: You can configure affiliate postbacks to be delayed. In that case, affiliates get only one “final” update once the conversion is settled. This avoids multiple updates but postpones reporting.
