Keitaro S2S Postback: Setup From Scratch

The Keitaro S2S postback is the exit door of the tracker: every conversion that reaches Keitaro can be forwarded onward - to a traffic source, an affiliate network, or an ad platform's server API - through an outgoing postback you configure. Get the setup right and conversions flow to every destination that deserves them; get it wrong and conversions arrive but never leave. This guide builds the setup from an empty campaign: what the postback does, the URL anatomy with its placeholders, status-based routing, the queue and dedup behavior, and the log checks that prove each delivery.

The incoming side - the postback URL the affiliate network calls - has its own walkthrough inside the network postback to CAPI guide; here the focus is outgoing delivery.

What Outgoing S2S Postbacks Do

Keitaro documents S2S postbacks as "a tool for analytics and data collection on the side of the traffic source": when a conversion is registered, Keitaro checks its status against every configured postback and queues the ones that match. The design has three consequences worth internalizing before setup:

1. Postbacks are per-campaign. Each campaign page carries its own S2S Postbacks tab - one campaign, one set of destinations.
2. Postbacks are status-keyed. Every postback row fires only for the conversion status selected on it; a lead-status postback and a sale-status postback are two separate rows.
3. Postbacks are queued. Outgoing requests are "collected in a queue and sent" separately from click processing - delivery survives restarts, and duplicates are excluded by the queue itself.

Because delivery is status-keyed, the postback grid is where your event policy lives: which statuses leave the tracker, and to where.

Building the Postback URL

Setup lives on the campaign page under S2S Postbacks, Add a postback. The three fields:

1. URL - "set the address where to send a postback," built with placeholders that Keitaro substitutes at send time.
2. Sending method - GET or POST, "which must be specified in the Source" - the destination defines what it accepts.
3. Status - the conversion status that triggers this postback.

A typical ad-platform or source-side URL carries the identity and the money:

https://destination.example/track?clickid={external_id}&event={status}&payout={conversion_revenue}

The placeholder that makes or breaks delivery is the click ID carrier {external_id}: "the click ID value from the Source is substituted," and an empty value means the source's traffic never passed the parameter - nothing to match on. Money rides {conversion_revenue}, state rides {status}, and campaign-level context uses the underscore family: {_sub_id_N}, {_offer_name}, {_campaign_name} (S2S postback documentation). The complete placeholder catalog - timestamps, currency conversions, status mappings like {status:lead=install sale=bill} - lives in the macros reference.

Status Routing: One Grid, Many Destinations

The status field on every postback row is the routing mechanism. A two-stream setup - the pattern from the hold status guide - is literally two rows:

Rejections map to nothing; rebills need the transaction parameter, as covered in the statuses guide. Because rows are per-campaign, the same policy repeats per campaign - which is why one delivery layer above the tracker, reading the same statuses, scales better than dozens of hand-copied rows.

The Queue, Dedup, and Logs

After setup, three behaviors define daily operation:

1. The queue. Requests "are collected in a queue and sent" separately - a destination outage does not lose conversions, it delays them.
2. The dedup. Duplicate conversions are excluded from the queue: an identical re-registration does not re-fire the postback. A changed conversion (new parameters on the same subid) overwrites the row first - the incoming-side rule from Keitaro's postback contract - and then re-fires.
3. The log. Maintenance, Logs, S2S postbacks shows "which subid initiates S2S sending, which link converted," and the destination's response. Errors in the response must be clarified with the destination - the log tells you what was said, not what the destination meant.

The queue-and-log pair is also the diagnostic loop for every downstream integration: when a platform-side report looks thin, the S2S log is the first witness.

Testing the Setup

The acceptance test has three checkpoints:

1. Fire a real conversion through the campaign (network test postbacks carry no real subid).
2. Read Maintenance, Logs, Postbacks: the conversion registered with the right status.
3. Read Maintenance, Logs, S2S postbacks: the outgoing row fired, the placeholders resolved - a non-empty {external_id}, a real payout - and the destination answered.

Free platform-side checks are available too: Pixel Activator verifies a Meta destination without infrastructure, and the postback troubleshooting checklist covers the failure modes in between.

Keitaro S2S Postback: Frequently Asked Questions

Sources