Postback not working

Introduction

Use this page only when the campaign is already live, the tracker or CRM should already be sending a callback, and the partner still does not credit the conversion correctly. This is not the architecture page and not the pre-launch QA checklist.

A broken production postback means lost payouts, misaligned attribution, and partner escalations with no shared evidence. The callback might never leave your infrastructure, might hit the endpoint and fail validation, or might return 200 while the partner still refuses to credit the event.

Explanation of the concept

Treat postback troubleshooting as a production triage exercise with three evidence layers: the original click and identifier, the conversion event inside your tracker or CRM, and the outgoing server-to-server callback. If one layer has no proof, the investigation stops there until that gap is closed.

This article should route you to the right branch. If you need to test a new integration before launch, use How to test a postback before launch. If the request reaches the partner and returns 200 but no conversion is credited, move to Postback Returns 200 but No Conversion. If the payload itself is wrong, compare it against the live request guide.

Keep one production evidence pack from start to finish: the redirect trace from Redirect Checker, the resolved identifier proof from Click ID Extractor, the callback replay from Postback Tester, and the raw endpoint response. That bundle makes it clear whether the break starts before the conversion event or inside the callback itself.

Common problems

Start by placing the incident into one of three buckets: delivery, transport, or payload. Delivery means the tracker never sent the callback. Transport means it tried to send but could not reach the partner cleanly. Payload means the request arrived but lacked the fields, formatting, or auth the partner expects.

This distinction matters because many teams waste hours editing postback templates while the real issue is a paused worker, a dead queue, an expired certificate, or a partner IP allowlist. Production failures are solved faster when every symptom is attached to the correct layer.

• Tracker logs show a conversion, but there is no evidence that any callback was attempted.
• The callback is attempted, but DNS, TLS, firewall, auth, or allowlist rules block delivery.
• The partner receives a request, but goal IDs, tokens, payout fields, or click IDs are missing or malformed.
• The partner changed endpoint rules, signatures, or accepted parameters without warning.
• Different teams edited templates, macros, or routing rules and no one updated the shared runbook.

Step-by-step troubleshooting

Work from proof, not assumptions. Confirm the click exists, confirm the conversion exists, confirm the callback was attempted, and only then start editing the request itself. A support ticket that contains only "postback not working" forces both sides to guess.

Your output should be a partner-ready evidence pack: click identifier, conversion timestamp, callback URL or template, exact request sent, raw response received, and the layer where the failure lives.

Group the incident by failure signature before you escalate. If the click never arrived, loop back to Redirect Checker and Click ID Extractor. If the payload shape changed, use the request-comparison workflow. If the partner accepts the call but still withholds credit, move into the strongest fix page instead of rerunning the same callback.

1. Prove the identifier existed at click time

   Use Redirect Checker and Click ID Extractor to confirm the original click carried the identifier that should later appear in the callback.

2. Confirm the conversion layer fired

   Inspect tracker or CRM logs and capture the exact conversion timestamp, goal, payout, and click ID. If the conversion event itself is missing, the postback is not the first problem.

3. Separate delivery from payload failure

   Check whether the tracker actually attempted automatic delivery. If not, investigate paused queues, workers, endpoint config, or background jobs before editing macros.

4. Replay the exact callback manually

   Use Postback Tester or Postback URL Checker to send the exact production payload to the partner and archive the response, latency, and any validation error. This isolates partner-side rejection from tracker-side delivery issues.

5. Escalate to the correct adjacent guide

   If the payload differs from the expected template, branch into the request-comparison guide. If the response is 200 but no conversion is credited, branch into the 200-but-no-conversion fix. If everything depends on a missing click ID, branch into the click-ID troubleshooting pages instead of changing callback templates.

Tools that help solve the problem

The tool stack should mirror the evidence stack. One tool proves the click, another proves the identifier, another replays the callback, and another keeps your server-side attribution ecosystem aligned when partners ask why postbacks and ad-platform events disagree.

Do not dump every artifact into a ticket. Send the smallest evidence set that proves where the failure lives.

The fastest path is usually: confirm arrival proof, replay the callback, compare template versus live request, then choose the smallest next-step page that matches the failure signature. That keeps teams from bouncing between generic QA pages when the real owner is already clear.

Conclusion

Postback incidents get expensive when teams jump straight into template edits without proving whether the callback left the tracker, reached the partner, or failed validation after arrival. Production debugging gets faster when each step ends with evidence, not opinion.

When the issue is fixed, update the runbook with the exact failure bucket, the evidence that proved it, and the adjacent guide that would have shortened the path next time.

Hand the case to the smallest next step: Fix postback not working for broad production failures, Postback Returns 200 but No Conversion for accepted-but-uncredited events, or How to test a postback when you need to rebuild the QA routine before the next launch.

Related issues

• Postback Not Working
• Postback Returns 200 but No Conversion
• Postback Macro Not Replaced