Keitaro integration with reliable server-to-server postbacks

The scenario

Imagine a product acquisition flow in which a click reaches a landing page and a later server event confirms a conversion. The reference integration would preserve the relationship between those two events. It would focus on traceable conversion reporting, with an explicit recovery path for missing or repeated callbacks.

Preserve the click identifier at the boundary

The landing flow would capture the tracker click identifier and associate it with an internal lead or account record when the flow permits. Keitaro uses subid to connect a postback with a recorded click. The application would preserve that value exactly instead of substituting its own customer ID.

The stored association would have a retention policy and an explicit missing-ID state. A conversion without a usable click reference would enter reconciliation rather than being assigned to an arbitrary campaign. Redirects and cross-domain handoffs would be tested with known synthetic clicks.

Define a conversion state machine

A Node.js endpoint would authenticate incoming callbacks using the provider’s supported mechanism, validate the schema, and store the provider event identity. Mapping rules would translate the product’s states to the configured tracker statuses. A pending event and a later approved event would be treated as a transition, not automatically as two independent conversions.

A database uniqueness rule would protect against repeated event deliveries. The durable conversion record would include received time, source time, current state, and delivery attempts. PostgreSQL conflict handling would support repeated inserts, while application rules would still decide which state transitions are allowed.

Deliver asynchronously and reconcile failures

A delivery worker would send the configured Keitaro postback after the conversion record commits. Transient failures would get bounded retries with backoff. Permanent validation failures would remain visible to an operator with a reason and a safe replay action.

Reconciliation would compare internal conversion records with tracker evidence using the click and conversion references. Logs would redact credentials and avoid storing full sensitive URLs. A successful HTTP response would be checked against the tracker’s documented response semantics before the delivery is marked complete.

What to validate

• A known test click receives the intended conversion.
• Repeated callbacks do not inflate conversion counts.
• Status updates follow the agreed transition rules.
• Failed deliveries can be inspected and safely replayed.

The tradeoff

Server-to-server delivery improves control over the reporting path, but cannot reconstruct a click ID that was never captured. Document attribution gaps and investigate them instead of manufacturing a complete-looking report.