Postback Tester
Captures the exact replay transcript you need when the partner says the callback never arrived.
Open tool >Postback troubleshooting
Postback Not Received
Trackers show callbacks firing, yet partners insist nothing arrived because firewalls or filters intercepted them.
Signal
Your tracker or replay tool shows a send attempt, but the partner cannot find the same request in its inbound logs.
Evidence
Keep one packet with replay transcript, timestamps, source IPs, endpoint URL, and the partner's lookup window.
Next step
Stay in this lane only while transport is the real problem; route accepted callbacks to the credit-repair guide.
Introduction
Postback Not Received is the branch where your tracker, CRM, or replay tool insists the callback was sent, yet the affiliate network, advertiser, or partner says nothing ever reached the receiving endpoint. This is not the same as an accepted callback with missing credit. It is a transport and receipt problem first, so the investigation has to prove exactly where the request disappeared.
Treat this page as the handoff between delivery logs and partner-side intake logs. Start with a single real conversion, save the callback from Postback Tester or Postback URL Checker, and compare that replay to what the automatic tracker job attempted to send. If you cannot prove the same URL, headers, and timestamp window, the rest of the escalation becomes guesswork.
This lane also depends on earlier classification. If callbacks never leave the queue, return to Fix postback not working. If the partner does receive a request but it still contains literal placeholders such as {clickid}, continue with Postback Macro Not Replaced. Stay here only when the system attempted real delivery and the missing receipt is the unresolved gap.
Why the problem happens
Receipt failures are expensive because they create a blame gap between teams. The tracker owner points to a sent event, the media team points to missing credit, and the partner points to empty logs. Unless you align all three views to one transaction and one minute-by-minute timeline, everyone ends up defending a different dataset.
Transport rules also change more often than teams expect. Networks add WAF rules, rotate secrets, move receiving infrastructure behind proxies, tighten TLS settings, or cap bursts from shared IP pools. Any of those changes can make a previously healthy callback disappear without an obvious application error.
That is why the safest workflow is to keep one evidence chain that starts with the original conversion and ends with the partner's inbound lookup. If the incident later turns out to be a mapping problem instead of a delivery problem, you can branch cleanly into the template-versus-live comparison guide or the accepted-credit branch without restarting the investigation.
- Partner WAF blocks your current outbound IP range or datacenter ASN.
- TLS, SNI, certificate, or cipher requirements changed and the handshake fails before the app sees the request.
- Shared secrets, auth headers, or query tokens rotated but the tracker still signs with stale credentials.
- A CDN, reverse proxy, or firewall silently drops large bodies, duplicate requests, or burst traffic.
Common causes
Most postback-not-received incidents fall into four buckets: outbound delivery never actually happened, the request left but died in transport, the request reached the perimeter and was filtered before the application logs it, or the partner searched the wrong identifiers and time window. Naming the bucket early prevents teams from mixing transport debugging with lookup confusion.
Outbound delivery problems usually hide in job workers, retry queues, or stale endpoint configuration. Transport problems show up as DNS failures, TCP resets, TLS negotiation errors, blocked egress, or timeouts. Perimeter filtering often comes from WAF, rate limits, IP allowlists, or signature checks that reject the request before the business application records it.
Lookup errors are quieter but common. A partner may search the wrong endpoint, the wrong shard, or the wrong timestamp window and conclude nothing arrived. That is why your proof packet should always include the exact URL path, method, time zone, source IP, and transaction keys from the callback you replayed.
- Firewall policies block outbound IPs or ports between your tracker and the receiving endpoint.
- Rate limits or bot defenses throttle bursts after queues recover or workers restart.
- Partners moved the intake endpoint, proxy, or secret while your template still points to the old path.
- Payloads exceed body-size limits, header limits, or signature-validation rules and get dropped before logging.
- The partner checks a different environment, offer, or reporting window and misses the delivered request.
Step-by-step troubleshooting
Work from one documented callback outward. The goal is not to prove that something failed in general; it is to prove where one specific request stopped being observable. When the same incident packet is reused across tracker logs, replay tools, firewall logs, and partner support, ownership becomes much easier to assign.
Do not retry the same callback repeatedly before you capture the first failure. Multiple near-identical requests can trigger rate limits or confuse partner searches. Save one replay, verify the exact payload, then trace the network path for that single attempt.
If delivery turns out to be healthy, stop here and route the case to the narrower branch that matches the evidence. The value of this page is classification, not endless replaying.
-
Export the exact outbound attempt
Capture the timestamp, request method, endpoint URL, response code, error body, source IP, and retry count from the tracker or CRM. Save the click ID, transaction ID, and offer context with the same record.
-
Replay with Postback Tester
Send the identical payload once from Postback Tester or inspect it in Postback URL Checker. Archive the full transcript so you can compare manual delivery against automatic delivery.
-
Verify the transport path
Confirm DNS resolution, outbound IPs, TLS support, certificates, firewall rules, proxies, and allowlists against the partner's current documentation. Ask specifically whether any recent WAF, CDN, or ingress changes affect callbacks.
-
Align partner-side lookup details
Share the transcript and ask the partner to search the same endpoint path, time zone, minute window, source IP, click ID, and transaction ID. Do not accept a generic 'nothing arrived' answer without confirming the exact lookup scope.
-
Route to the next narrow fix
If the request never left your stack, go back to Fix postback not working. If it arrived with literal placeholders, continue with Postback Macro Not Replaced. If it was accepted but still did not credit, move to the accepted-but-uncredited guide.
Tools that help solve the problem
Use a small tool chain that proves send attempt, payload shape, and original click context without opening unrelated investigations. When every artifact comes from the same conversion window, transport escalations become harder to dismiss.
The replay transcript is usually stronger than screenshots from a dashboard. Pair it with the original landing-path evidence and the callback template so infrastructure, partner support, and tracker owners are all reviewing the same object.
Archive the outputs together. If the request is later found in a queue, proxy, or dead-letter log, you want the exact same payload available for comparison rather than rebuilding it from memory.
Postback URL Builder
Keeps macros, auth tokens, and endpoint parameters aligned when you recreate the failing payload.
Open tool >tools.postback_url_checker.title
Lets you inspect the callback URL structure, encoding, and query parameters before replaying the request.
Redirect Checker
Regenerates the original landing-path proof so you can tie the callback back to a valid click and session.
Open tool >Conclusion
Treat postback-not-received incidents as evidence problems, not opinion problems. Once you can show the same callback in your logs, your replay tool, and the partner's search window, the missing layer becomes much easier to isolate.
After the incident closes, document the final cause in the runbook that owns callbacks for that partner: changed endpoint, rotated secret, missing allowlist, proxy filter, or lookup mistake. That record is what prevents the same integration from failing silently on the next deployment or scaling spike.
If transport is no longer the blocker, stop replaying and branch immediately to the broader postback troubleshooting guide or the credit-repair workflow. The fastest fix usually comes from classifying the incident correctly, not from sending the same request ten more times.