How to test a postback

Introduction

Use this page before launch, during partner onboarding, or whenever a callback template changes materially. The goal is to prove the integration works before paid traffic and revenue depend on it.

This is not the same job as defining what postback tracking is, and it is not the same job as triaging a live outage. Here you are building evidence that the setup is ready for production.

Explanation of the concept

A useful postback test covers three pillars: inputs, processing, and outputs. Inputs mean fresh click IDs and realistic conversion values. Processing means macros, auth, encoding, and template logic. Outputs mean the partner response plus the logs that prove the callback really happened.

Pre-launch QA should also produce acceptance criteria. A test is not done when one request returns 200; it is done when the team can show which payload was sent, which fields were required, what the partner logged, and what should happen if a field is intentionally broken.

Common problems

Most QA failures are process failures. Teams test the wrong environment, skip negative cases, or fail to save the exact payload and response. When the campaign goes live, nobody can prove what was actually validated.

Another common mistake is letting pre-launch QA drift into live-fire troubleshooting. If the real issue already affects production traffic, stop using this page and switch to the production incident guide.

• Running tests on staging endpoints when production behaves differently.
• Using hard-coded click IDs that do not exist in partner logs.
• Skipping authentication headers or signing routines during QA.
• Ignoring the time it takes for partners to log test conversions.
• Failing to save the HTTP response and assuming the test succeeded.

Step-by-step troubleshooting

Treat QA runs as controlled experiments with explicit pass and fail conditions. Capture the click URL, the template version, the exact payload, the raw response, and what the partner confirms on their side.

The output should be a launch-ready evidence bundle, not just a feeling that the integration looks fine.

1. Generate fresh clicks

   Use Redirect Checker to produce fresh clicks and make sure the identifiers you test with could exist in the partner workflow.

2. Record the identifiers and expected mapping

   Use Click ID Extractor to log the exact IDs you plan to use and note which macro or payload field each value should populate.

3. Review the template and auth rules

   Use UTM Builder or your tracker UI to confirm macros, encoding, auth tokens, currency format, and the endpoint contract you expect the partner to validate.

4. Send a valid test and a controlled failure

   Use Postback Tester to send one known-good payload and one intentionally broken payload. Record both responses so you can prove that validation works in both directions.

5. Archive sign-off before launch

   Save the final request, response, partner confirmation, and any mirrored server-side event checks. If production later breaks, this bundle becomes the baseline for the incident guide.

Tools that help solve the problem

Standardizing the toolkit keeps QA fast. Redirect Checker produces real clicks, Click ID Extractor documents identifiers, UTM Builder keeps templates organized, Postback Tester fires the requests, and Facebook CAPI Tester ensures parity with ad platforms.

Automate as much as possible - store scripts and logs in your repo so testers can rerun them quickly.

Conclusion

Postback QA is valuable only when it is reproducible. Save every request, response, and sign-off artifact so the launch team can prove what was approved before spend starts.

Once real traffic is live, stop using this page as your main incident runbook. Production failures belong in the live troubleshooting page, using the pre-launch evidence bundle as the baseline.