Refuse leads

Users with access to a specific Offer can view its details together with allowed propagation options (Link, iFrame, API).

For iFrame or API submissions, the Admin can configure whether unwanted leads should be rejected. This can be applied to iFrame only, API only, or to both.

How leads can be rejected

If rejection is enabled in the Offer settings, under Form or API, a lead may be refused at three points:

• Validation – the lead must pass the rules on the fields it carries, whether that is a field type, a regex or a validation scenario. See Field validation.
• Offer Filters – the lead must satisfy the Offer’s filter conditions to be eligible for processing. See Filters.
• Lead Processing Result – the lead must be accepted by at least one channel in the pingtree. If no channel accepts it, it is refused.

You can choose which of these a lead must pass before being approved:

• Everything – validation, filters, and pingtree processing.
• Validation – field and external validation only.
• Filters – the Offer filters only.
• Pingtree – acceptance by at least one channel only.

Who the rule applies to

Each rejection rule carries two partner lists. Both answer the same question, which is who the rule applies to.

• Included partners – only the partners on this list are affected. Everyone else is left alone.
• Excluded partners – everyone is affected except the partners on this list.

The lists are read in a fixed order:

• If the include list has anyone on it, only that list counts. The exclude list is ignored completely.
• If the include list is empty, the exclude list applies to everyone else.
• If both lists are empty, the rule applies to every partner.

This means you cannot use both lists together to build an exception. Putting a partner on the include list and on the exclude list at the same time leaves them affected, because the include list wins and the exclude list is never read.

Pick one list per rule:

• Use the include list when the rule is meant for a few named partners.
• Use the exclude list when the rule is meant for everyone except a few.

You can have several rules on one offer, each with its own lists and its own set of checks. They are evaluated in order, and a lead is refused as soon as one rule that applies to the partner rejects it. Rules are also separate for iFrame and API, so a partner can be covered by an API rule and not by an iFrame one.

If a partner needs a completely different setup, duplicating the offer for them is usually clearer than stacking rules.

Lead Approval and Rejection

If lead refusal is disabled, the status is always approved. Every lead is marked approved, even if it would not have met the criteria.

If lead refusal is enabled:

• The status starts as pending until processing is complete.
• If the lead meets the criteria, the status changes to approved.
• If it does not, the status changes to rejected.

Sample API response:

{
  "process_id": "9e886baa-6804-4dfe-baf9-a065b66d7f87",
  "status": "pending",
  "url": "https://portal.paldock.com/tenant/processes/9e886baa-6804-4dfe-baf9-a065b66d7f87"
}

Choosing what to check

The four options are not four levels of strictness, they are four different questions.

• Validation asks whether the data is usable. Turning it on rejects leads the partner could have fixed, which is fair to tell them about.
• Filters asks whether you want this lead at all. A duplicate or a lead outside your target group is rejected here even though the data is perfect.
• Pingtree asks whether anyone bought it. This is the strictest in practice, because it makes the partner’s payment depend on your advertisers, not only on the quality of their traffic.

Partners notice the difference. A lead rejected because the phone number was wrong is a conversation about data quality. A lead rejected because every advertiser was capped that afternoon is a conversation about your inventory.

Tracking Lead Status

Affiliates may want to track the status of each lead, whether it was approved or rejected. PalDock provides several ways to obtain this information. For full details, see API integration.

Verification

Rejection has to be immediate, because the customer is waiting to be redirected. Verification is not immediate, because it waits for the customer to do something, for example confirm a code or sign a document.

The two cannot both be true at once, so verification resolves it this way:

• The lead is set to approved when it reaches the verification step, and the customer is redirected.
• It stays approved whatever happens next. A customer who never completes the verification does not turn the lead into rejected, and neither does a channel that later declines it.

So approved means the lead passed the checks you set and was handed over. It does not mean it was sold.

Whether the customer finished, and whether the advertiser eventually paid, is a separate question answered by the transaction rather than by the lead status. An offer with verification will normally show more approved leads than transactions, and that gap is the verification drop-off, not a fault.

Tell partners this before they build their reporting on the lead status. A partner who counts approved leads as sales will be wrong by exactly that gap.