Connection Creator in Tracking

Beyond building integrations to send or receive leads, PalDock’s Connection Creator can also be used purely for tracking purposes – confirming, updating, or influencing the outcome of a conversion after the initial lead was already delivered. This is what we call Connection Creator in Tracking.

There are two distinct levels to this:

1. S2S postback
2. Tracking API

Both levels use the same visual Connection Creator editor, but the intent and the trigger are different.

S2S Postback (Incoming to PalDock)

An S2S (server-to-server) postback is triggered when an advertiser calls PalDock, typically to report the final result of a conversion (approved / rejected, sale value, loan amount, etc.).

Two ways to use it

1. Passive receipt (the simple case)

At its simplest, an incoming postback just records the data the advertiser sends – status, result, or a value – and stores it against the lead/transaction. No further logic is needed.

2. Active processing inside the scenario

The more powerful use is to let the scenario act on the incoming data. For example to send another request in case the S2S postback contains incomplete data, or to calculate commission dynamically based on a value the advertiser sends. But it has many uses.

Example: commission tiers based on loan amount

The advertiser sends a parameter (e.g. {value}) representing the approved principal of a loan. The scenario then branches on that value and sets the resulting {commission} accordingly:

• {value} < 500 → {commission} = 10 USD
• {value} < 800 (and ≥ 50 000) → {commission} = 17 USD
• {value} ≥ 800 → {commission} = 23 USD

In the blueprint this is built with:

• A single startNode (incoming_postback) as the entry point.
• Multiple outgoing edges from the start node, each with a condition comparing {value} against a threshold (is_less_than, is_greater_than_or_equals, etc.) – see the Conditions card, where Value is the picked system parameter (value under Commission), Operator and Output define the threshold.
• One setNode per branch (“Set Value” card), which writes a literal amount into {commission} (key: commission, value: e.g. 1000).

This is exactly the pattern to reference when explaining conditional branching on an incoming postback: conditions live on the edges leaving the start node, and each branch ends in a setNode that writes the final {commission}.

Advanced: formulas on top of the base commission

Once {commission} is set, it can be referenced later in a formula field in commissions, such as “{commission}+10” for a VIP group. This lets you keep one shared base commission logic (the incoming postback scenario) while giving specific partner groups an uplift on top, without duplicating the whole scenario per group.

Tracking API (Outgoing from PalDock)

The Tracking API is PalDock actively querying the advertiser’s system, rather than waiting for the advertiser to call us.

Unlike the incoming postback (which is event-driven – it fires when the advertiser sends data), the outgoing postback is scenario-driven by default: it is PalDock that decides when to check, how often to retry, and how long to wait before giving up.

Use case 1 – Status polling and processing the result

This is the most common use case: periodically ask the advertiser’s API for the current status of a lead/application, and once a final state is reached, update the transaction accordingly (e.g. approved / rejected), and read out a {value} or {commission} from the response to store on the transaction.

Typical blueprint pattern:

1. startNode (outgoing_postback, flow: instant).
2. Optional waitNode (e.g. 12h) before the first check, to give the advertiser’s system time to process the lead.
3. Optional modifyFieldNode to build authentication (e.g. Base64-encoding login:secret into a Basic auth header).
4. httpNode (GET) – “Get status” – calling the advertiser’s status endpoint with the external lead ID.
5. Conditional edges out of the httpNode based on the returned status field (e.g. parsedBody.state or parsedBody.status):
   • A terminal rejected state → setNode writing {result} = rejected (and {type} = sale) → endNode.
   • A terminal approved/issued/sold state → setNode writing {result} = approved (optionally also {commission} = {parsedBody.price} or similar, pulling the payout directly from the advertiser’s response) → endNode.
   • Any other (pending) state, matched with a regex_not_match against the known terminal values → routed into a retry loop.
6. The retry loop uses a breakerNode (e.g. “Breaker 6x”, maxRepetition: 6) combined with a waitNode (e.g. 24h) that loops back into the same httpNode. This caps the number of retries so the flow does not poll indefinitely – after the breaker’s limit is reached, the flow simply stops without a final state (which should be treated as “unresolved” downstream).

This pattern – wait → check → branch (rejected / approved / pending-with-retry-cap) – is the backbone of most Tracking API integrations and should be the reference example when documenting outgoing postback status polling.

Use case 2 – Sending data to a specific user

The Tracking API can also be used the other way around: to push data to a specific advertiser/partner, from PalDock’s side. From that advertiser’s point of view, this behaves like an incoming postback to them – but on PalDock’s side it is still configured and triggered as an outgoing postback scenario (PalDock decides when to call out and what to send).

Use case 3 – Sending data to ad systems

The same mechanism is used to forward conversion or event data into advertising platforms (ad systems), either:

• Globally, for the whole account/system, or
• Per specific account/campaign, scoped to individual advertisers or partners.

These follow the standard conditions available elsewhere in PalDock (status/result matching, value thresholds, etc.) to decide what gets sent and when the same condition/edge mechanics used throughout the Connection Creator.