Skip to content
Browse documentation

Partner postbacks are failing or not firing

Diagnose outgoing postbacks that fail, never fire, fire with empty values or were paused automatically.

Last updated 4 min read

On this page

Start in Reporting → Postback log → Delivery log. Filter by Affiliate and State, then open Details on a row to see the expanded URL, the HTTP status and the first 500 characters of the response.

The postback never fired (no row in the Delivery log)#

Check, in this order:

  1. Was the conversion approved? Approved conversions postbacks fire only for approved conversions. Pending conversions (default status pending, hold period, throttle, a hold rule) fire when they are approved. Rejected and duplicate conversions never fire, unless the postback uses Custom statuses… with rejected ticked.
  2. Is the postback active? A paused postback fires nothing — including one paused automatically (see below).
  3. Does it match the conversion?
    • The postback's Affiliate is the conversion's partner, or it is workspace-wide;
    • its Offer and Event match (or are "All");
    • private events fire only workspace-wide postbacks that name that event — never partner postbacks;
    • Skip conversions with a zero payout is off, or the payout is not 0.
  4. Did it already fire? Each postback fires at most once per conversion. Approving a conversion that already fired (for example a Approved and pending postback that fired while pending) does not fire it again.
  5. Is it a Reversals postback? Those fire only for an approved conversion that is rejected (by advertiser postback, in the panel, by API, CSV import, in the advertiser portal or by fraud scoring) or re-priced by an advertiser postback — never when a pending conversion is rejected, and only once per conversion.

Use Send test on the postback to rule out the endpoint, and test=1 on the advertiser postback to see which postbacks a conversion would queue (details.postbacks, workspace token only).

The row is failed#

Error / HTTPMeaningFix
HTTP 404, HTTP 400The partner's endpoint rejects the request: wrong path or missing parameter.Compare the expanded URL with the partner's documentation.
HTTP 401 / 403The endpoint wants authentication or blocks our IP.Add an Authorization header under Custom headers; ask the partner to allowlist the server IPs shown in the form and the user agent ArcTrack-Postback/1.0 (a fixed technical identifier).
HTTP 5xx, timeouts, connection refusedThe endpoint is down or slower than 10 seconds.Retries run for about 8.5 hours; then use Retry failed.
invalid postback URLThe URL is not a valid absolute http(s) URL after macro expansion.Fix the template.
destination address not allowed (private, loopback or link-local)The host resolves to a private IP.Use a public endpoint.
stopped after 3 redirectsThe endpoint redirects in a loop.Use the final URL.
conversion rejectedThe conversion was rejected (or marked duplicate) before delivery.Expected; nothing to fix.
html postback not delivered: …HTML postbacks run only from an iframe or JavaScript conversion pixel.Use an S2S or Image pixel postback, or have the advertiser use the iframe / JS pixel.
conversion API delivery is not configuredA conversion-API destination without its integration.Configure it under Integrations.

After fixing the cause, select the rows → Retry selected, or Retry failed for all failures in the filter. A retry re-sends the same expanded URL; it does not pick up template changes.

"Delivered" but the partner did not count it#

TrackCrown treats any HTTP 2xx as delivered and ignores the body. Many trackers answer 200 with an error message. Open Details and read Response; typical causes:

  • the partner's click ID is not in the macro you used (presets assume the partner put it in sub1);
  • the partner expects different status values (approved vs 1);
  • the partner de-duplicates by transaction ID: send {conversion_id}.

Values are empty or literal#

SymptomCause
A placeholder arrives as text, e.g. {payuot}Misspelt macro; unknown macros are left untouched. The form warns "Unknown macros are sent literally".
{revenue}, {advertiser_id}, {old_revenue} emptyPartner-created postbacks never receive network money.
{sub1} emptyThe click had no sub1 (or the conversion has no click).
{email} emptyThe postback fired later (approval, hold) — the address is never stored.
{sub6} … {sub10}, {coupon_code} sent literallyThe postback fired from a panel / API / CSV approval, where these are not substituted. Use sub1–sub5.
{ip}, {user_agent} emptyThe postback fired from a hold release or a reversal postback.

See Postback macros.

Paused automatically#

If every delivery of a postback failed for more than 72 hours (at least 10 failures, no success since it was last saved), the worker pauses it and notifies your team ("Postback to <host> paused") and the partner. To resume, fix the endpoint, then Activate it (row menu) or save it with the switch on Active.

Postbacks are slow#

Deliveries normally leave within seconds. If Queued / retrying keeps growing with old Next attempt times, the delivery worker is not running — contact your platform administrator. Retries of a failing endpoint are expected to wait (1 min, 5 min, 30 min, 2 h, 6 h).

Something unclear or missing in this article?Tell us