How a partner postback connects to a Telegram route

A partner postback is a server request reporting an outcome recorded by a partner. In a Telegram funnel, your integration must connect that claim to a stored route and decide which event to send onward. Receipt alone establishes neither a deposit nor advertising attribution.

Start with the deposit postback contract for the partner's fields and the join-to-deposit identity link for the records connecting the two actions. This guide checks the handoffs between those records.

Trace the request through separate records

Choose one transaction and ask each system owner for the corresponding record. Record the time zone as well as the timestamp. A partner ledger entry establishes what the partner recorded; an access log establishes what reached your endpoint.

The route record is part of your implementation. Confirm how it is created and which identifier connects it to a click id. Do not assume that a Telegram link automatically carries the advertising identifier.

Check the tracker contract before replaying

Keitaro's documentation requires subid and status for correct postback processing. The tracker uses subid to find the click. An absent status, or an unknown status without configured mapping, can leave the request ignored. Compare the actual received values with your configured contract.

The optional tid identifies a transaction and is used to record repeated conversions without overwriting the previous one. Keitaro also documents that a repeated request with the same subid and different parameters can overwrite a previous conversion. When all parameters match, the postback is processed but the S2S postback is not sent again. Those are Keitaro rules, not a universal resend policy.

Before replaying anything, establish whether it represents a new transaction, a correction or the same delivery attempt. Use an agreed test destination where possible. A replay against a live endpoint can change records or trigger onward delivery.

Establish what Telegram actually observed

The Bot API's chat_member update reports a change in a chat member's status. Receiving it requires the bot to be an administrator and to list chat_member explicitly in allowed_updates. Confirm these settings before diagnosing an absent update.

Telegram also has separate payment-related and subscription update types. Their existence does not turn a membership update into proof of a deposit at a partner's off-platform cashier. Reconcile that deposit against the partner's transaction record.

Inspect both directions of the identifier exchange: how your route key reaches the partner and how the callback returns it. Check the field name, value and lookup result. If the callback contains a literal placeholder instead of a value, repair the template before investigating the advertising report. A test assembled on your side checks your receiver; it cannot prove the partner emitted the original request.

Review each advertising destination independently

One configured destination may reject an event while another accepts it. Keep a request and processing result for each destination instead of treating one blended counter as proof of delivery everywhere.

For Google Ads offline imports, the help page states a 90-day limit after the associated last click and a separate 63-day limit for enhanced conversions for leads. The configured conversion window is a different condition. An event inside the import deadline can still fall outside the relevant conversion window.

Google also documents about three hours for imported statistics to appear. For a conversion-time comparison, use the documented conversion-time reporting column rather than assuming every report groups by the event date. These conditions do not establish that your upload matched an eligible ad interaction.

Resolve the first unproven handoff

If the sender has no record, request it before changing your receiver. If ingress exists but correlation fails, inspect the identifier exchange. If correlation succeeds but nothing is sent, inspect the status mapping and queue result. If a destination accepted the request, continue with its diagnostics and reporting rules.

For a period-wide discrepancy, use Telegram funnel reconciliation. For a route that produces no requests, use the postback troubleshooting checklist. Record unknown outcomes as unknown; a successful synthetic request cannot replace the missing evidence from the original transaction.

Sources