S2S postbacks explained

S2S postbacks explained in brief

A server-to-server (S2S) postback is KiwiWall’s way of reporting a conversion directly from an offer action endpoint to your backend systems without browser-only pixels in the critical loop. In practice, it gives you cleaner attribution data, better retry control, and less dependence on client-side scripts that can be blocked by privacy controls.

For a team that needs scale or strict traffic-quality control, S2S is usually the default because it gives you:

• deterministic click-to-conversion mapping via stable IDs,
• explicit rejection reasons for failed payouts,
• and the ability to harden attribution logic independently of page rendering changes.

If you are deciding now, start with this rule: if postback reliability affects revenue reconciliation, reporting trust, or payout disputes, you should design S2S first and treat all other tracking as supporting telemetry.

Who this is for

• Publishers: owners of offerwalls, media sites, and app traffic who need reliable conversion accounting and fast debugging when payouts drift.
• Advertisers: campaign operators managing CPA/CPI/CPL offers who need trustworthy validation before changing payouts, caps, or traffic acceptance.
• Technical teams: integration owners who need an auditable flow for retries, deduplication, and rejection-handling.

Definition

An S2S postback is a backend HTTP call sent after a qualifying conversion event is confirmed. Unlike browser pixels, which are triggered in the user context, S2S traffic is sent directly between systems using server identity and server-side identifiers.

In KiwiWall language:

• Click event occurs when a user engages a tracked offer path (for example, from a placement, wall tile, or rewarded offer CTA).
• Conversion event occurs after the advertiser (or offer provider chain) confirms an approved action.
• S2S postback is the conversion event packet sent back to KiwiWall with identifiers and status.

The result is a single source-of-truth conversion record that can be reconciled against campaign caps, publisher payout logic, anti-fraud checks, and disputes. S2S postbacks are only useful when your upstream systems can produce stable IDs and your backend can process retries without creating duplicate conversions.

Decision table

⚪ means optional, not wrong; it means the team can use hybrid tracking but should still design S2S fallback paths.

When S2S is not the right first choice

Use a non-S2S-first setup only when you are testing one offer for less than 72 hours, cannot guarantee stable IDs yet, or do not have an owner for conversion disputes. In those cases, scope a short hardening window and migrate.

How it works

1) Capture a single click schema at the wall edge

Every tracked click should emit:

• click_id (system-generated, unique per click),
• offer_id,
• publisher_id,
• optional routing metadata (sub1, sub2, etc.),
• and source context (geo, device class, placement).

If this is inconsistent at click time, every downstream metric becomes unreliable. Use this as your first acceptance gate.

2) Carry identifiers through conversion endpoints

As the user converts, the downstream path must preserve your IDs in a tamper-resistant, standardized form. Do not rely on browser session values only; server processes should also receive IDs in server-authenticated parameters.

At minimum, KiwiWall teams care about:

• stable click_id correlation,
• transaction_id uniqueness,
• and event outcome fields (pending, approved, rejected) with reason.

3) Emit the postback to KiwiWall

After conversion approval:

• KiwiWall receives the S2S callback with required identifiers,
• your endpoint signs or validates the request according to partner contract,
• and postback processor maps it to existing click records.

If the record is new and valid, conversion status advances; if not, it is either rejected, queued for retry, or flagged for manual review depending on policy.

4) Normalize dedup and latency windows

Duplicate callbacks happen: browser retries, retries from advertiser systems, and delayed network deliveries.

Operationally:

• treat same transaction_id + short dedupe window as a potential duplicate,
• keep a bounded retry count with clear terminal states,
• separate “late valid” and “invalid duplicate” handling,
• avoid writing duplicate revenue.

This protects both publisher payout trust and advertiser reconciliation.

5) Enforce rejection logic and routing controls

With KiwiWall routing, rejection codes should become actionable:

• Hard rejects: traffic quality issues, invalid offer mapping, blocked geo.
• Soft rejects: temporary infra failures that are eligible for retry.
• Manual holds: flagged fraud or compliance exceptions.

The routing layer should choose whether to block subsequent volume from the same source or continue with stricter thresholds.

6) Reconcile at the campaign level

Never reconcile only by raw conversion counts. For KiwiWall, reconcile at least:

• approved conversion count,
• rejected conversion count with reason buckets,
• effective payout per source,
• and conversion latency distribution by segment.

That combination catches issues where total volume rises but money reliability is degrading.

Parent context and adjacent reads:

• Start here from the fraud and tracking hub: Performance tracking and fraud control hub
• For identifier details, review Postback URL parameters
• For mismatch symptoms, jump to How to debug postback mismatches

Example: launch flow for one publisher stack

A media publisher team runs two placements across web and mobile. They route offers through KiwiWall and split by geography.

1. Day 1: they define one click_id format and pass it in every click payload, plus sub1 for traffic source and sub2 for placement.
2. Day 2: technical checks confirm the server receives all expected identifiers at conversion handoff.
3. Day 3: first postbacks arrive; 1% arrive duplicate, so they set a short dedupe window and suppress repeated writes while preserving first-touch status.
4. Day 4: they discover one partner sends delayed callbacks; they tighten retry classification to avoid false payout rejection on temporary transport errors.
5. Day 6: fraud team identifies one placement with elevated rejection reasons; they keep the placement live but reduce cap and activate stricter controls.
6. Day 7: reconciliation shows accepted/rejected behavior stable enough to open scaling by second placement and one adjacent geo.

Common mistakes and fixes

1. Using different ID keys across environments.
   Fix: publish one canonical key dictionary, same across staging and production.

2. Treating retries as new conversions.
   Fix: enforce dedupe using transaction_id + offer_id + bounded time window.

3. Ignoring soft rejects as noise.
   Fix: instrument soft reject reason rates per partner and per placement daily.

4. Over-relying on browser pixels for truth.
   Fix: use pixel or client telemetry only for diagnostics, not payout truth.

5. Publishing without SLA boundaries.
   Fix: set explicit acceptance criteria before launch.

Checklist

• Define and freeze canonical ID fields (click_id, transaction_id, offer_id).
• Align partner and webhook naming rules with KiwiWall reconciliation logic.
• Add signed validation or explicit allowlist for callback sources.
• Implement idempotency handling for duplicate callbacks.
• Separate hard reject vs soft reject reason buckets.
• Add conversion latency and late-callback alerts.
• Create a rollback-safe dedupe window and retry policy.
• Add a dispute runbook with owner, severity, and response SLA.
• Run a 48-hour staging replay test with synthetic duplicate and delayed callbacks.
• Verify final data is traceable to placement/geo/source tags before volume increases.

FAQ

Do postbacks replace pixels entirely?

No. Pixels can still help in diagnostics and front-end instrumentation, but S2S should be the attribution authority for payout-critical paths.

What do we do when callbacks are delayed for hours?

Treat delayed callbacks as normal for some partners if documented. Track whether they are soft errors, transport stalls, or conversion-state drift. Delay classification should be operational policy, not a manual panic response.

How do we reduce duplicate conversions?

Use idempotency and strict dedupe keys. If your current callbacks have mixed fields across systems, normalize before acceptance, not after.

Why does postback acceptance drop after scaling?

Typically one of: routing rule mismatch, ID propagation breaks, or retry explosion. Check identifiers first, then rejection reason distribution, then partner-specific timing.

Is S2S required for fraud prevention?

S2S is a prerequisite for mature fraud control because it gives you hard evidence for disputes and reconciliation, but it must be paired with offer routing controls and quality policies.

Conversion link

If your organization is ready to operationalize, move from learning to implementation by starting the KiwiWall integration setup in Platform.

Evidence notes

• Strategy source: docs/content-silo-plan.md (2026-06-18), no drift against Obsidian vault as of last sync.
• Keyword/market validation references used for this page placement:
  • EVID-KS-20260618-1
  • EVID-KS-20260618-2
  • EVID-KS-20260618-4
  • EVID-KS-20260618-5