The Tracking API is a tool for exchanging conversion data between systems in a structured and automated way. It allows PalDock to send or request information about conversions from another system, ensuring data stays synchronized without manual updates. 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, 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:
- Transaction (all) – (default) – fires on any change to a transaction (create or update)
- Transaction created – fires only when a new transaction is created
- Transaction updated – fires only when an existing transaction is updated
- Conversion (all) – fires on any change to a conversion (create or update)
- Conversion created – fires only when a new conversion is created
- Conversion updated – fires only when an existing conversion is updated
👉 In 90% of cases, you will use the Transaction (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 4, 5
- A new conversion (sale) without commission → triggers 4, 5
- A conversion (lead) created via iframe and immediately updated with cookie data via pixel → triggers 4, 5, 6
- 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, 4, 5, 6
- Updates for both conversions and transactions are handled as separate events, and their triggers fire independently. The only exception is when the AutoApprove feature is applied. In that case, the result is set immediately when the transaction is created, and the transaction update event is not sent. On the contrary, when the AutoSet feature is applied, it is considered a transaction update.
- A new conversion (sale) which created transaction → triggers 1, 2, 4, 5 (conversion created + transaction created)
- A conversion (sale) updated with a value change → triggers 1, 3, 4, 7 (conversion updated + transaction updated)
- The same conversion (sale) updated again, this time with a result change → triggers 1, 3, 4, 7 (conversion updated + transaction updated)
⚡ 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).
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 cascade 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 Changes” 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.
- Only if the transaction is created with the AutoApprove feature enabled will the affiliate receive the result approved immediately, meaning no pending update is sent.
- 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 one.
- 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.