One value has to survive the entire journey
Imagine one normal affiliate conversion. A publisher sends a visitor to an offer. OfferDaemon creates a unique click_id for that visit and sends it to the advertiser in the landing-page URL. When the visitor converts, the advertiser returns the same value to OfferDaemon.
OfferDaemon uses that returned click_id to find the original click, offer, and publisher. If the value is missing, changed, or sent under a name OfferDaemon does not accept, the conversion cannot be connected to the click.
The normal OfferDaemon flow is simple: send
{click_id}to the advertiser, save the value, then return it in an S2S postback asclick_idorcid.
An advertiser's order or lead number has a different job. Sent as tx_id, it helps OfferDaemon recognize a repeated S2S postback and avoid recording the same conversion twice. It does not replace the click ID used to find the original traffic source.
The real OfferDaemon flow
The example below follows the URL structure used by OfferDaemon. The domains and IDs are examples, but the OfferDaemon links, placeholders, and accepted field names are real.
-
The publisher sends traffic through OfferDaemon The generated link contains
offerandaff, which identify the offer and publisher. -
OfferDaemon creates a unique click_id OfferDaemon creates one value for this visit and saves it with the offer and publisher.
-
The advertiser receives the click ID OfferDaemon replaces
{click_id}in the offer URL. The advertiser may call its receiving fieldclickid,subid, or something else. -
The advertiser stores the value with the lead or sale The exact rendered click ID must remain attached to the advertiser's transaction until the conversion is reported.
-
The advertiser sends an S2S postback to OfferDaemon The saved value comes back as
click_idorcid. The advertiser can also include the conversion type, amount, currency, and its own order or lead number. -
OfferDaemon checks and records the result It finds the click, checks for a duplicate and applicable offer rules, then records the outcome in the Postback Log.
1. The publisher tracking link
https://track.yournetwork.com/click
?offer=solar-lead
&aff=publisher-uuid
OfferDaemon generates this link in the publisher's offer view. Do not remove offer or aff. A publisher who also uses an external tracker can add external_click_id; that separate value is explained later in this guide.
2. The offer URL template configured by the admin
https://advertiser.example/landing
?clickid={click_id}
Here clickid is the field name chosen by the advertiser. {click_id} is the OfferDaemon placeholder. When a visitor clicks, OfferDaemon replaces the placeholder with the real Click ID:
https://advertiser.example/landing
?clickid=7kQ9xR2mN4pL1sTv8wYz3a
3. The advertiser's S2S postback to OfferDaemon
https://dashboard.yournetwork.com/postback
?click_id=7kQ9xR2mN4pL1sTv8wYz3a
&tx_id=order_1042
&event=sale
&amount=49.00
¤cy=USD
Notice the name change. The advertiser received the value in its own clickid field, but returns that value to OfferDaemon as click_id. The value stays the same. Only the field name changes to the one OfferDaemon recognizes.
Values OfferDaemon accepts in an S2S postback
For normal tracked traffic, the advertiser sends click_id in the OfferDaemon S2S postback. OfferDaemon also accepts cid, which makes the setup easier with trackers such as BeMob.
| OfferDaemon field | Other accepted name | What it does |
|---|---|---|
click_id |
cid |
Finds the original tracked click and connects the conversion to the right offer and publisher. This is the recommended setup. |
tx_id |
transaction_id, txid |
Carries the advertiser's order, lead, or invoice number. OfferDaemon uses it to recognize repeats and make reporting easier to compare. |
event |
event_type |
Accepts lead, sale, recurring, refund, or custom. Defaults to lead. |
amount |
payout |
Passes the conversion value. It is required for normal RevShare calculation, but does not override the publisher payout. |
currency |
None | Passes the three-letter currency code. The default is USD. |
offer_id + publisher_id |
offer + aff |
Identifies the offer and publisher when the conversion did not start with a tracked click. Always use these two values together. |
country |
None | Optionally supplies a two-letter country code that takes precedence over click-derived country. |
clickid is not accepted in an OfferDaemon S2S postback.
An advertiser or publisher tracker may use that name on its own side. When the advertiser reports a conversion to OfferDaemon, it must send the saved value as click_id or cid.
The supported BeMob-style version
https://dashboard.yournetwork.com/postback
?cid=7kQ9xR2mN4pL1sTv8wYz3a
&payout=49.00
&txid=order_1042
&event=sale
In this version, cid means click_id, payout means amount, and txid means tx_id. If both accepted names are included for the same value, OfferDaemon uses the standard one.
How OfferDaemon handles duplicates and event types
Keep the same order or lead number when retrying
Send the advertiser's order, lead, or invoice number as tx_id. If the advertiser sends the same conversion again, it should reuse the same value. OfferDaemon can then mark it as a duplicate instead of creating a second conversion.
If no tx_id is sent, OfferDaemon uses the Click ID to check for repeats. That can be enough for a simple one-click, one-conversion offer, but an advertiser's real order or lead number makes reporting much easier to compare.
Only use the supported event names
OfferDaemon accepts lead, sale, recurring, refund, and custom. If event is omitted, the conversion is recorded as lead. If the advertiser uses a different name, such as approved, declined, or deposit, change it to one of the OfferDaemon names before sending the S2S postback.
Recurring conversions must be enabled on the offer
Use event=recurring for repeat billing only when the offer allows recurring conversions. Each new payment should have its own advertiser order or invoice number in tx_id. Sending the same invoice again with the same number is a repeat, not a new payment.
Refunds use their own event
Send event=refund when the offer supports refunds. Do not try to approve, reject, or reverse a conversion by adding status to the advertiser's S2S postback. Conversion approval is handled separately in Admin > Conversions.
A conversion without a tracked click is the exception
When there is no tracked click, OfferDaemon can identify a conversion with offer_id plus publisher_id, or offer plus aff. Use this only when the advertiser genuinely cannot return a Click ID. The standard click_id flow is easier to check and gives you a clear connection to the original visit.
click_id, which value it sends as the order or lead number, how its conversion types match OfferDaemon event names, and whether a RevShare offer needs amount.
click_id and external_click_id belong to different systems
OfferDaemon can carry two different click identifiers in the same conversion flow. They belong to different systems and solve different problems.
| Value | Created by | Used for |
|---|---|---|
click_id |
OfferDaemon | Connects the advertiser's S2S postback to the OfferDaemon click, offer, and publisher. |
external_click_id |
The publisher's tracker | Lets OfferDaemon send the conversion back to the publisher's own tracker. |
How a publisher passes its tracker ID into OfferDaemon
The publisher adds external_click_id to the tracking link. Before sending the visitor, its tracker inserts the real value:
https://track.yournetwork.com/click
?offer=solar-lead
&aff=publisher-uuid
&external_click_id=publisher_click_78421
How OfferDaemon notifies the publisher's tracker
The publisher saves its notification URL in Profile > Your postback URL. For example:
https://publisher-tracker.example/postback
?clickid={external_click_id}
&payout={payout}
&status={status}
&event={event}
¤cy={currency}
&txid={txid}
In this URL, clickid is the name used by the publisher's tracker. OfferDaemon replaces {external_click_id} with the publisher's original value. It can also send the payout, status, event, currency, offer ID, advertiser order or lead number, and sub1 through sub10 values shown above.
OfferDaemon sends this notification after it creates a publisher conversion. The publisher should confirm that the notification arrived in their tracker and compare the result with OfferDaemon reports.
Start troubleshooting in the Postback Log
Open Admin > Logs > Postback Log before comparing spreadsheets or payout totals. The log shows what OfferDaemon received and why it did or did not create a conversion.
| Postback Log result | What it means | What to check |
|---|---|---|
| Missing Parameters | OfferDaemon received neither click_id/cid nor both the offer and publisher IDs. |
Check whether the advertiser sent clickid instead of the supported click_id. |
| Click Not Found | A click ID arrived, but it does not match a click stored by OfferDaemon. | Compare the value received by the advertiser with the value returned to OfferDaemon, character by character. |
| Duplicate | The same conversion event was already processed. | Confirm the advertiser reused the same order or lead number in tx_id. Do not invent a new number just to avoid this result. |
| Zero Amount | A RevShare S2S postback arrived without a usable amount or payout. |
Check the advertiser's amount field and confirm it sent a value greater than zero. |
| Invalid Event | The S2S postback used a conversion type outside OfferDaemon's supported list. | Map the advertiser's value to lead, sale, recurring, refund, or custom. |
| Refund Blocked | The offer does not allow the requested refund path. | Review the offer settings before resending the event. |
| GEO, Cap, or Dust result | The click was found, but an offer rule stopped normal conversion creation. | Review the click country, offer limits, and Dust Threshold instead of changing the click ID. |
| Accepted | OfferDaemon created the conversion record. | Open Admin > Conversions to see whether it is Pending or Approved. |
The fastest diagnostic order
- Open Admin > Reporting > Clicks and confirm the click exists.
- Confirm the advertiser received the same click ID in its
clickid,subid, or equivalent field. - Open Admin > Logs > Postback Log and search for that value.
- Open the received URL and the result shown by OfferDaemon. Check the field names before checking the amounts.
- If the result is Accepted, open Admin > Conversions and review the conversion status.
- If publisher notifications are enabled, confirm that the publisher's tracker received one.
This follows the click from creation to conversion. It tells you which handoff failed instead of leaving you to compare two final reports with no explanation.
Test one real OfferDaemon conversion safely
A useful test starts with a real OfferDaemon tracking click. Typing a made-up click ID into /postback only proves that OfferDaemon correctly reports Click Not Found.
- Create a test offer and test publisher. Keep the test away from live financial reporting.
- Add the OfferDaemon Click ID placeholder to the offer URL. For example:
https://advertiser.example/landing?clickid={click_id}. - Generate and open the publisher tracking link. Use the normal
/click?offer=...&aff=...link from the publisher offer page. - Confirm the advertiser received a real value. The final landing URL must contain something like
clickid=7kQ9xR2mN4pL1sTv8wYz3a, not the literal text{click_id}. - Confirm the click in OfferDaemon. Open Admin > Reporting > Clicks and find the same Click ID.
- Send one S2S postback. Use that Click ID, a unique test
tx_id, and the values needed by the offer. - Check the result. Open Admin > Logs > Postback Log, then Admin > Conversions.
- Send the exact same S2S postback once more. OfferDaemon should report a duplicate instead of creating a second conversion.
A ready-to-use OfferDaemon test
Replace the domain with your OfferDaemon dashboard domain and the Click ID with a real click from your test offer:
curl --fail-with-body --get \
'https://dashboard.yournetwork.com/postback' \
--data-urlencode 'click_id=7kQ9xR2mN4pL1sTv8wYz3a' \
--data-urlencode 'tx_id=test_order_1042' \
--data-urlencode 'event=sale' \
--data-urlencode 'amount=49.00' \
--data-urlencode 'currency=USD'
When OfferDaemon accepts the S2S postback, it shows {"status":"ok"}. Sending the exact same one again should show {"status":"duplicate"}. Confirm both results in the Postback Log.
amount affects the calculated payout.
Where each part lives in OfferDaemon
You do not need to assemble the complete integration from memory. Each screen answers one practical question.
Add {click_id} to the offer URL under the field name expected by the advertiser, for example clickid={click_id}.
Start with the ready-to-copy standard URL. Use the BeMob-compatible version only when the sender needs cid, payout, and txid.
Search by Click ID or the advertiser's order or lead number. OfferDaemon shows the URL it received and what happened next.
The publisher saves a notification URL with OfferDaemon placeholders such as {external_click_id} and {payout}.
For the complete list of supported values, open the OfferDaemon Postback Parameters documentation. If you are moving this setup from another platform, use the migration checklist before changing live links.
Checklist before sending live traffic
Use this list with the advertiser or tracker team. Every item should have a concrete answer.
- The offer URL contains the OfferDaemon
{click_id}placeholder. - The advertiser knows which landing-page field receives that value.
- The advertiser stores the exact Click ID it received with the conversion.
- The return URL uses
click_idorcid, not an unsupportedclickidfield. - The advertiser reuses the same order or lead number in
tx_idwhen it sends a conversion again. - The advertiser's conversion type matches
lead,sale,recurring,refund, orcustom. - RevShare integrations send a usable
amountorpayout. - A real test click appears in Admin > Reporting > Clicks.
- The first test and one identical replay appear correctly in the Postback Log.
- If publisher notifications are enabled,
external_click_idwas saved from the original tracking link.
OfferDaemon S2S postback FAQ
Does OfferDaemon accept clickid in an S2S postback?
No. Use click_id or cid. The advertiser may use clickid on its landing page, but it must return that saved value to OfferDaemon as click_id or cid.
What is the difference between click_id and external_click_id?
click_id is created by OfferDaemon and comes back from the advertiser. external_click_id comes from the publisher's tracker and lets OfferDaemon notify that tracker about the conversion.
Does payout override what the publisher earns?
No. In the advertiser's S2S postback, payout is simply another accepted name for amount. Publisher earnings still follow the offer's payout model and any publisher-specific rate settings.
Is event required?
No. OfferDaemon uses lead when event is missing. Send another value only when you need sale, recurring, refund, or custom.
How does an advertiser send an S2S postback to OfferDaemon?
Copy the ready-to-use S2S postback URL from Admin > Settings > Postback URL. The advertiser adds the saved Click ID and conversion details to that URL, then sends it when a lead or sale happens.
Can OfferDaemon create a conversion without click_id?
Yes. The advertiser can send offer_id plus publisher_id, or offer plus aff. For normal tracked traffic, click_id is recommended because it connects the conversion to an actual click.
Will the publisher's tracker always receive the notification?
Delivery is not guaranteed. Confirm that the notification arrived in the publisher's tracker and compare it with OfferDaemon reports.
Exact OfferDaemon references
This guide was checked on July 29, 2026 against the current OfferDaemon product behavior and public documentation.
- Postback Parameters: values accepted in an advertiser S2S postback, alternative field names, conversion types, amounts, and troubleshooting.
- Postback Setup: where admins copy postback URLs and inspect outcomes.
-
Publisher Tracking Links:
offer,aff, andexternal_click_id. - Publisher Postback URL: values OfferDaemon can send in a publisher notification and how delivery works.