Postback Tester
Replay the exact callback and store the HTTP response you got back.
Открыть инструмент >Postback troubleshooting
Postback Returns 200 but No Conversion
The endpoint answers successfully, but the network, tracker, or CRM still does not record the conversion you expected.
Symptoms
This issue appears when a postback request gets a 200 response, so teams assume everything is healthy, but the conversion never shows up in the affiliate network, partner dashboard, or internal reporting system. The transport layer looks fine while the business event is still missing.
It is common during new offer launches, tracker migrations, or partner endpoint changes. The callback is technically accepted, but one of the required identifiers, goal values, or validation rules still prevents the receiving system from crediting the conversion.
Why this happens
A 200 response only proves the server answered. It does not prove the partner created a conversion record. Many endpoints return success for syntactically valid requests even when they ignore the payload internally because a click ID is stale, the payout field is blank, or the goal name does not match their setup.
That is why this problem sits between broad delivery failures and explicit macro failures. The request leaves your side, but the receiving system still has a semantic reason to discard it.
- The endpoint accepts the request but silently ignores an expired or unknown click ID.
- The postback carries the wrong goal, status, or payout format even though the URL is valid.
- The partner logs the request as a test or duplicate event instead of a real conversion.
Common causes
Most cases fall into three buckets: identifier mismatch, business-rule mismatch, or duplicate suppression. Start there before you blame the transport layer.
The cleanest investigations compare the expected conversion template against the exact callback that returned 200, then confirm how the receiving side interpreted that request.
- The click ID in the callback never existed, already expired, or belongs to a different offer.
- The endpoint expects a different goal name, event status, or payout field than the one you sent.
- A previous test already used the same identifier, so the partner suppresses duplicates but still returns 200.
- Macros resolved to empty values, so the request was accepted but could not be mapped to a sale.
How to check it
The fastest path is to prove three layers in order: the source click exists, the callback payload contains the right values, and the receiving side can match that payload to a conversion record.
Do not start by editing the template blindly. First capture one failing callback that returned 200 and inspect it side by side with the partner specification.
-
Verify the source click and conversion input
Use Postback Tester or your tracker logs to confirm the click ID, goal, payout, and timestamp you believe should create the conversion.
-
Review the callback URL separately
Open the request in Postback URL Checker and confirm that identifiers, goal parameters, and auth fields are really present.
-
Compare expected versus live payload
Match the callback that returned 200 against the partner's required template. If placeholders stayed literal, continue with Postback Macro Not Replaced.
-
Ask how the partner classified the request
Confirm whether they treated it as duplicate, invalid, stale, test, or unmatched. A successful HTTP response is not enough without that business-layer answer.
How to fix it
Fix the exact mismatch that prevented the 200-response callback from becoming a conversion. That usually means replacing one wrong identifier, goal name, or mapping field rather than rebuilding the whole transport stack.
Once corrected, rerun the same scenario with a fresh click and save both the request and the partner confirmation so the next launch has a reference.
-
Generate a fresh test click
Use the real landing path or a controlled QA click so you are not retesting with stale identifiers that will never be accepted.
-
Align the callback with the partner spec
Update the template, goal mapping, payout format, or status fields so the payload matches the endpoint's current rules.
-
Retest with Postback Tester
Replay the corrected request in Postback Tester and archive the response plus the partner-side conversion proof.
-
Escalate broader delivery issues only if needed
If the callback stops returning 200 or never leaves the tracker, branch into Fix postback not working instead of mixing transport and payload problems.
Relevant tools
Use the tester to replay the callback, the URL checker to inspect the payload structure, and the broader postback fixes only when you prove the problem is not a simple mapping mismatch.
This cluster works best when you keep one failing request, one corrected request, and one partner confirmation side by side.
Postback URL Builder
Rebuild the callback template cleanly once you know which field or macro is wrong.
Открыть инструмент >Redirect Checker
Generate or verify the original click path when you need to prove the source identifier was valid.
Открыть инструмент >Click ID Extractor
Inspect the click ID or tracking parameter when the receiving side claims it cannot match the request.
Открыть инструмент >Выводы
Treat '200 but no conversion' as a mapping problem until proven otherwise. The server answered, but the event still failed the partner's internal logic.
Keep a reference pack with the approved template, a fresh valid click, the successful test callback, and the partner confirmation. That evidence is what keeps future postback launches fast and predictable.
FAQ
Частые вопросы
Can a 200 response still mean the conversion failed?
Yes. It usually means the endpoint accepted the HTTP request, not that the partner created a conversion record. Business validation can still reject the event internally.
When should we move to postback-not-working instead?
Move there when the callback no longer leaves the tracker, returns transport errors, or the endpoint becomes unreachable. This page is for callbacks that technically succeed but still do not credit the conversion.
What if the callback contains literal placeholders?
That is a different failure mode. Continue with <a href="/fix/postback-macro-not-replaced" class="text-blue-600 font-semibold">Postback Macro Not Replaced</a> and fix the macro substitution first.