Test Postback URL

Why run this before launch

Dry-run before campaign launch

Use fake order IDs and sandbox payouts so finance, partners, and compliance all sign off before you spend a dollar.

• Paste the partner URL exactly as they provided it, macros and all.
• Swap payout, currency, and status values with small QA numbers that are easy to reconcile.
• Attach the captured 200 response to your pre-launch QA doc so approvals go faster.

Run this checklist before traffic starts.

Validate callbacks before broken postbacks cost you revenue

Postback Tester helps you reproduce real callback flows, inspect raw responses, and confirm that tracker or network postbacks behave correctly before live conversions are at stake. It is most useful when you treat the callback as one layer in a broader attribution chain that also includes the resolved landing page, the click identifier stored on that page, and the downstream system that should later credit the conversion.

• Replay sample GET or POST callbacks that mimic Keitaro, Binom, RedTrack, Voluum, or partner traffic sources.
• Inspect status codes, latency, headers, and response bodies in one place instead of debugging blind.
• Capture proof for partner managers, tracker admins, or finance teams when a callback fails.
• Decide faster whether the next owner is the tracker template, the partner endpoint, the click-ID capture layer, or the post-conversion reporting workflow.

Use it when

• •

  Running a pre-launch callback test before paid traffic and real payouts start.

• •

  Debugging a partner-side callback failure with evidence instead of screenshots and guesses.

• •

  QAing Keitaro or Binom callback flows after tracker, offer, or network changes.

Practical use cases

Recovery workflow for production postback issues

A strong postback investigation stays ordered. First confirm the visitor and click identifier reached the correct landing page, then confirm the conversion event exists in the tracker or CRM, and only then replay the outbound callback. This prevents teams from editing templates blindly when the real gap lives upstream or in partner-side validation.

Evidence to collect before escalating a postback bug

Most postback incidents stall because each team captures different artifacts. Keep one minimal proof set so network support, tracker admins, and revenue teams can all review the same facts.

• The original campaign URL or tracker link that generated the click.

• The Redirect Checker trace showing the final landing page and whether query parameters changed mid-route.

• A Click ID Extractor snapshot proving which identifier reached the landing page before conversion.

• The exact callback URL or payload you replayed, including auth fields, payout, status, and goal naming.

• The raw response body, status code, headers, and latency returned by the partner endpoint.

• The partner or tracker log entry you expect to match against the replayed test.

Common reasons postback tests still mislead teams

A successful HTTP response is useful, but it is not the same thing as a healthy attribution workflow. Use these checks to avoid false confidence.

• The callback returns 200 but the partner ignores the event because goal names, currency, deduplication keys, or auth fields are still wrong.

• The payload is technically valid, but it no longer matches the identifier format the landing page or CRM actually stored.

• A team keeps replaying a clean test callback even though the live issue starts earlier in redirect routing, click-ID capture, or conversion logging.

• Finance, CRM, and tracker owners each review different screenshots, so nobody notices that the callback and the conversion record refer to different transactions.

Related postback QA pages

Common postback failures to review next

If the test request returns a response but the conversion still does not appear correctly, move straight to the fix guide for macro replacement issues or the broader delivery checklist before changing tracker settings blindly.