Conversion postbacks
Fire a URL when a lead is accepted by a buyer or reported sold, so your tracker or ad platform optimizes on real outcomes.
Fire a URL when a lead is accepted by a buyer, or when it is reported sold. Use it to tell RedTrack, Everflow, Voluum or your own system. Each lead triggers a postback once.
Postbacks are off by default. Turn them on in Settings → Conversion postbacks on the pipeline; a Postbacks step then appears at the bottom of the canvas, after the routing outcome, and opens the list.
Add a postback
Click Add postback, then fill the card:
| Field | What it does |
|---|---|
| Name | How the postback reads in the lead's timeline and in the counters. |
| Trigger | On accepted fires when a delivery reaches a buyer, or when the buyer's response says yes (see reading the buyer's response). On sold fires when the lead is reported sold, from the buyer portal, the API or the lead page. |
| Method | GET puts everything in the URL. POST sends a JSON body as well. |
| URL | The tracker's URL, with merge codes for the lead's values. Must start with https://. |
| Only for source | Fire only for leads that came in through one of the pipeline's sources. Default: any source. |
| Only when accepted by | Fire only when a specific buyer is the one who took the lead. Default: any buyer. |
| Body template | POST only. A JSON body with merge codes, like a webhook body template. Leave it empty to send the default envelope (lead id, buyer, price, lead fields). |
A postback fires once per lead. In a pipeline that sends every lead to all matching buyers, the first accepted delivery fires it; the others do not. A lead reported sold, then lost, then sold again fires the sold postback once.
Merge codes
Write {field} anywhere in the URL or the body. A code is replaced by the lead's value, percent-encoded in the URL so an email or a name never breaks the query string.
- Any field of the pipeline:
{rtclickid},{first_name},{zip}, exactly as the field is named in Intake. - Lead codes:
{lead_id},{email},{phone},{source},{pipeline},{buyer},{quality_score},{quality_grade},{timestamp}. - Delivery codes:
{price}(the amount billed for the delivery that triggered),{currency},{delivery_id}. - Conversion codes, filled on On sold only:
{conversion_amount}and{conversion_label}, as the buyer reported them. Empty on an accepted trigger.
Modifiers work as in body templates: {zip|upper}, {phone|phone:e164}, {created|date:MM/DD/YYYY}.
A typical pair for a tracker:
Only for a source or a buyer
Both filters narrow the postback; leave them on Any to fire for every lead. A postback for a Meta tracker usually keeps Only for source on the Meta source, so leads posted by another vendor never reach that tracker. Only when accepted by is for the case where a conversion only counts with one buyer.
When a postback is skipped
If a merge code in the URL is empty on the lead, the postback is skipped: nothing is sent, and the lead's timeline says which code was empty ("skipped · rtclickid is empty"). A tracker pinged without its click id learns nothing and pollutes its own numbers, so a half-filled URL is never sent.
A skipped postback is not retried on its own: the value will not appear by itself. If you add it to the lead afterwards, use Resend on the lead page.
A code that is not a field of the pipeline
The URL editor flags a code that does not match a field of the pipeline or one of the codes above. It renders empty, and the postback is skipped for every lead. Fix the spelling or add the field in Intake.
Testing
Send a test on a postback card renders the URL against the latest routed lead of the pipeline, shows it, and calls it for real. You see the HTTP status and the response time ("HTTP 200 · 84 ms") and can unfold the response body. Nothing is recorded: the test never uses the lead's one real postback, and it does not appear in the timeline or the counters.
If the lead has no value for one of the codes, the test says so and sends nothing, exactly like the live send would.
Where to see what was sent
- On the lead page, the Postbacks card lists each postback with its status, time and HTTP code, or the skip reason. Open What was sent on a line to read the exact request: the method and the full URL as it left (with a copy button), the body for a POST, the tracker's answer with its HTTP status and how long it took, and the attempt number with its time. A skipped line opens on the URL template instead, so you can see which merge code was empty. Resend appears on a failed or skipped postback; never on a sent one, since a second ping is a second conversion for the tracker.
- In the lead's activity: "Postback "RedTrack Lead" sent · HTTP 200", "… skipped · rtclickid is empty", "… failed · HTTP 500 after 3 attempts".
- On each card in the Postbacks panel: the last 30 days, as "12 sent · 1 failed · 3 skipped", and under it Recent sends, the last ten leads this postback fired for, each with its status and a link to the lead page for the full request.
A failed postback (the tracker answered with an error, or did not answer) is retried automatically, three attempts in all. After that it stays failed until you resend it. The card keeps the last attempt only.
Common questions
Does a rejected delivery fire the accepted postback?
No. A delivery the buyer's response turned down is rejected, not delivered, and fires nothing. That is the point of pairing postbacks with buyer response rules: your ad platform optimizes on leads the buyer took.
Can a postback fire for a lead that failed delivery and was re-run? Yes, once the re-run delivers. The postback fires on the transition to delivered, whichever attempt gets there.
Where does the sold trigger come from? From the lead's reported outcome: the buyer marks it sold in the portal or through the API, or you set the outcome on the lead page. Whoever reports it, the postback fires once.
Is the URL stored somewhere? The rendered URL, the POST body and the tracker's response are kept with the postback record on the lead, like a delivery keeps its request body. The activity log keeps the name, trigger, status and reason only.