Postback Tester
Captures the exact request and response so you can prove whether the callback left your stack and how the receiver answered.
Open tool >Postback troubleshooting
Postback Not Working
Networks show zero conversions because callbacks never trigger, leave the queue late, or fail partner validation.
Signal
A broken postback usually fails in one of three places: queue, transport, or partner-side validation.
Evidence
Keep one packet with click proof, callback proof, and the exact response from the receiving endpoint.
Next step
Route accepted-but-uncredited cases to the credit-repair guide instead of repeating delivery tests.
Introduction
Postback Not Working appears when trackers register conversions yet affiliate dashboards stay flat. The event exists somewhere in your funnel, but the callback that should export it to the network, advertiser, or CRM never completes the full trip with the right identifiers, payout fields, and approval context.
Treat this page as the delivery-first runbook for live incidents. If the callback already returns success but the conversion still never receives credit, move to Postback Returns 200 but No Conversion. If placeholders like {clickid} or {payout} survive into the final request, branch into Postback Macro Not Replaced instead of restarting the same transport checks.
A reliable investigation starts with one real click and one real conversion. Save the landing-path proof from Redirect Checker, confirm the visible identifier with Click ID Extractor, and then compare that evidence to the callback you send from Postback Tester or Postback URL Checker.
Why the problem happens
Postbacks close the loop between media spend and payouts. When they fail, ad platforms lose optimization signals, finance cannot reconcile revenue to traffic, and partner managers start questioning whether conversions are missing because of quality, fraud, or integration debt.
This issue is expensive because the broken layer is rarely the one the team first inspects. Media buyers often look at campaign spend, developers look at endpoint availability, and partner teams look at approved sales. Unless one owner can prove the same click ID, transaction ID, and payout across those systems, everyone discusses a different incident.
That is why the Postback not working knowledge-base guide and the live-request comparison article matter here. They help you classify whether the failure belongs to callback generation, transport, template mapping, or partner-side business rules before another revenue day is lost.
- Offer templates change macro names but teams keep using the previous callback.
- Partners tighten security (HTTPS, signatures, allowlists) without warning.
- Tracker job queues pause during deployments and no one notices until the queue overflows.
- One offer works while another fails because the callback path, goal mapping, or authentication token diverged silently.
Common causes
Group incidents into delivery, transport, and payload buckets before you touch production settings. Delivery means the callback never left the tracker or queue. Transport means the request was attempted but blocked by TLS, firewall, DNS, or rate limiting. Payload means the partner received the request structure but rejected one or more fields that the business logic needs.
Delivery failures usually show up as missing queue workers, paused jobs, expired credentials, or a conversion event that never reached the system responsible for firing callbacks. Transport failures appear as connection errors, timeouts, handshake mismatches, or allowlist gaps. Payload failures are quieter: the request leaves cleanly, but the receiving side answers with a warning, a soft rejection, or a response that looks healthy while credit still does not happen.
Separate those buckets early because each one points to a different owner. Delivery issues belong to the tracker or automation stack. Transport issues belong to infrastructure or network security. Payload issues belong to whoever owns macros, identifiers, goal mapping, and partner-side acceptance rules.
- Background workers crashed or credentials expired so nothing leaves the queue.
- Firewall or TLS mismatches block the connection.
- Missing goal IDs, currency, or payout fields make partners drop the event.
- The callback fires with an old endpoint, stale secret, or wrong offer-level parameter set.
- The conversion exists, but the callback reuses the wrong click ID or transaction key from another step.
Step-by-step troubleshooting
Work outward from the tracker instead of guessing from the partner dashboard. Prove the conversion exists, rebuild the callback, replay it once, and inspect whether automatic delivery follows the same path. One documented replay is useful; five random retries only blur the timeline.
Keep timestamps, click IDs, transaction IDs, payout values, and goal names together from the first step. If you later compare a replay to the wrong landing-page session or the wrong partner log line, the investigation loops back into speculation.
Once the failing layer is obvious, stop broad debugging and route the case to the narrowest next fix. That is how you shorten outages instead of creating longer incident notes.
-
Capture a fresh conversion
Pull the click ID, transaction ID, goal, payout, status, and timestamp from the tracker or CRM. Confirm that the same identifiers are still visible on the landing path with Redirect Checker and Click ID Extractor.
-
Rebuild the template
Use Postback Builder or the approved partner snippet to insert the captured values, confirm macro names, and verify encoding before you blame the endpoint.
-
Run Postback Tester
Send the callback manually from Postback Tester or inspect it in Postback URL Checker. Archive the full URL, headers, body, status code, latency, and any error text for the exact replay you will discuss with other owners.
-
Check automatic delivery
Review queue workers, retry logs, webhook jobs, and outbound request traces to ensure the automatic callback is actually leaving the tracker without errors and using the same payload you just tested manually.
-
Route the incident to the right branch
If nothing left the tracker, keep working this page. If the request leaves but does not arrive, continue with Postback Not Received. If the request arrives with literal placeholders, move to Postback Macro Not Replaced. If the partner answers 200 but no credit appears, escalate with the credit-repair guide.
Tools that help solve the problem
Use a short tool chain that proves one layer at a time. The goal is not to open every utility page, but to keep one incident packet that a tracker owner, infrastructure owner, and partner manager can all verify without reinterpretation.
Start with landing-path proof, then replay proof, then partner-side lookup proof. When those artifacts come from the same click and conversion window, the ownership handoff becomes fast and defensible.
Archive the exact outputs you send to the next owner. Screenshots of dashboards are weaker than the replay transcript, redirect trace, and raw callback body tied to one transaction.
Postback URL Builder
Keeps macro names, auth parameters, and payout fields aligned with the approved partner template.
Open tool >Redirect Checker
Confirms the original click still reached the expected landing URL with identifiers intact before conversion.
Open tool >Click ID Extractor
Verifies the browser-visible click ID or related parameter that the callback is supposed to reuse downstream.
Open tool >Conclusion
Document the root cause in the same format every time: click proof, callback proof, partner response, and final owner. That record turns the next incident from a fresh argument into a known branch with an approved checklist.
After the fix ships, update the callback template, credentials, allowlists, or worker monitoring at the source. The real goal is not just to revive one conversion, but to keep the next deployment from silently pausing callbacks again.
If the delivery layer is clean and the partner still refuses credit, stop calling it a transport incident. Hand the case to the accepted-but-uncredited workflow with the same evidence packet so the next owner starts from proof instead of assumptions.