Keitaro Conversion Status: What to Do With Each

A Keitaro conversion status is not metadata - it is the steering wheel of the whole delivery system. The status decides which outgoing postback fires, which platform event the conversion becomes, and whether the money reaches your reports or stays an annotation. Keitaro documents a specific status list, validation rules for how statuses can change, and per-status postback routing; this guide walks all three and ends with the status-to-event mapping that feeds your pixels.

The strategic question - which statuses deserve platform events at all - is covered in the hold status guide; this page stays on the mechanics Keitaro documents.

The Documented Status List

Keitaro's postback contract requires a status on every incoming conversion: "Without subid and status, the tracker cannot correctly process the postback." Its documented examples are lead, sale, rejected, registration, deposit, and trash (Keitaro postback documentation) - a vocabulary that maps cleanly onto affiliate funnel stages:

Two statuses deserve emphasis. deposit is a first-class documented status - which is exactly what deposit and FTD verticals need without custom vocabulary (the wiring lives in the FTD guide). And trash exists as a real status, not a workaround: known junk gets stored under its own name, kept out of every event stream by design.

Status Transitions: How a Record Changes

Affiliate conversions change status: a lead becomes a sale, sometimes a sale is clawed back. Keitaro models this as transitions configured per conversion type in the settings, and the validation is explicit in the troubleshooting documentation - the logged error "Conversion cannot transition to sale: next status already exists for the sent conversion but not for the existing one" means the requested move is not in the transition rules (postback troubleshooting).

Its complement is the overwrite rule: a new postback with the same subid but changed parameters overwrites the earlier conversion's row. Together the two rules produce the lifecycle:

1. The network posts lead on a subid; the row is created.
2. Confirmation arrives as a sale postback on the same subid; the transition is allowed, the row updates.
3. A rejection arrives as rejected; depending on the configured transitions, the row moves or the update is refused - either way, deliberately.

When a status is refused, the fix is configuration, not retry: add the missing transition or the missing conversion type ("Conversion type not found" has the same cure) in the settings.

Mapping Statuses to Platform Events

Status-to-event mapping happens in the S2S postback grid: every row selects a status and a destination, so the lead stream and the sale stream are separate rows with separate URLs (S2S postbacks). {status} carries the status name outward, and {status:mapping} - for example {status:lead=install sale=bill rejected=trash} - renames statuses per destination without touching the tracker's records (S2S postback placeholders).

The mapping table worth writing down before wiring:

1. registration and lead - lead-class events, if your policy sends them at all.
2. deposit and sale - money events with value; which one maps to Purchase depends on the vertical, as in the FTD wiring.
3. rejected and trash - no platform event, ever.
4. Everything else - a deliberate decision, not a default: unmapped statuses are silent, and silence is the correct outcome for statuses you have not decided on.

Corrections: What Each Status Allows

Statuses change after the fact, and the contract handles it: the same-subid overwrite updates the row when parameters change, and the payout parameter "supports positive and negative values" - clawbacks ride the same field as earnings (postback URL). At the platform side, sent events stand - which is why the correction happens in status policy before delivery, as the hold guide argues in depth.

The daily verification for all of this is two logs: Postbacks for what arrived and how rows changed, S2S postbacks for what left and what answered (logs).

Keitaro Conversion Status: Frequently Asked Questions

Sources