Incoming Postbacks

Conversions don't fire themselves. They arrive as server-to-server postbacks from your advertiser or network, sent to a postback URL you've given them, formatted however that platform decided to format them. The unglamorous truth in affiliate tracking is that postback senders get it wrong constantly — they swap the click-ID parameter for the dynamic-value parameter, they send the click ID in a custom field instead of the standard one, they include junk in a slot that should be empty, they format dates in a way the receiving tracker doesn't expect.

Most tracking platforms reject those malformed postbacks silently. The conversion isn't recorded, you don't get notified, and you find out by noticing a gap in the conversion graph weeks later — if you notice at all. Routy doesn't. The postback endpoint accepts the standard format, recovers what it can from the malformed ones, records the conversion, and opens an Issue in your portal so you can see exactly what was wrong and fix it upstream.

After setting up incoming postbacks, the following becomes available:

• A standard postback URL per traffic source. The URL is yours and you give it to any advertiser or network you partner with. GET or POST, your choice — both are supported and behave identically on Routy's side.
• Auto-correction for common tracker mistakes: swapped clickId and dynamic parameter slots, click IDs sent in the wrong parameter, junk in fields that should be empty, invalid formats. Where Routy can safely recover the conversion, it does. Where it can't, the postback gets logged with the reason it failed.
• An Issue opened in your portal every time auto-correction kicks in. The Issue includes the raw postback as received, the correction Routy applied, and the source it came from — so you can take the information to the advertiser, get the tracker config fixed at the source, and stop the corruption rather than just patching around it.
• Per-traffic-source postback URLs. Each ad network gets its own endpoint, which knows the format and click-ID parameter that network sends. So Google Ads gets a Google-formatted endpoint, Meta gets a Meta-formatted endpoint, and a custom CPA network gets a custom endpoint tuned to its conventions. No single URL trying to handle every format.
• Conversion-type filtering — the postback can carry an event name (signup, purchase, FTD, etc.), and Routy routes the conversion into the right bucket. If an advertiser sends a "Registration" event but your reporting categorises it as "Signup," you can map the rename in one place rather than across every report.

The Issue tracker is the part most operations come to value most. The auto-correction is what saves the conversion today; the Issue is what gets the underlying tracker fixed so you don't have to keep recovering the same broken postback every week.

You generate a postback URL per traffic source from the postbacks section of your Routy dashboard. The URL looks like your-domain.com/postback?clickid={click_id}&amount={amount}&event={event_name} — the placeholders get replaced by the values the advertiser sends.

You give that URL to the advertiser or network and ask them to fire it on every conversion. When a conversion happens, the advertiser's tracker calls your postback URL with the relevant values. Routy:

1. Validates the click ID against the original click record.
2. Applies auto-corrections if the format is recoverable (e.g. click ID and dynamic value swapped).
3. Records the conversion against the original click.
4. Opens an Issue if any correction was applied or if the postback couldn't be matched.

The whole round-trip — postback received, validated, recorded, and visible in your reporting — usually completes inside a few hundred milliseconds.

A few details worth knowing:

• Click-ID lookup is fast (sub-millisecond) for clicks within the last 90 days, and slower for older clicks. Conversions for clicks older than 12 months may fail the lookup depending on your retention settings.
• Postback retries are the sender's responsibility. If the advertiser's tracker retries a failed postback, Routy deduplicates by click ID so the conversion isn't double-counted.
• The Issue queue is reviewable in the dashboard. Issues stay open until you resolve them; resolving an Issue doesn't change the conversion itself, just marks the problem as acknowledged.

Most affiliate operations underestimate how much revenue silent postback failures cost them. The standard estimate from the tracking industry is that 5-15% of all postbacks have some kind of formatting error, and on platforms that reject malformed postbacks silently, those translate directly into lost conversions and lost revenue. For an operation pushing 10,000 conversions a month at an average payout of $50, even a 5% silent-loss rate is $25,000/month in unrecorded revenue.

Routy's auto-correction recovers most of those. The conversions that would have been silently dropped get recorded, the Issue gets opened, and you both keep the revenue and learn about the underlying problem. Over the first few weeks of running it, most operations end up with a backlog of Issues that, once fixed at the advertiser side, eliminate the recurring loss going forward.

The Issue queue also turns the postback ecosystem from "trust the advertiser" to "verify the advertiser." Once you can see which networks have well-configured trackers and which don't, you have data to take into commercial conversations — including the conversation about why a particular network's reported numbers don't match yours.