Built-in tracker: postbacks and HMAC signing

A postback is the network telling AdFleet about a conversion. The quick way: "Tracker" → "Postbacks" → "Connect a network" (Owner, Head, Team lead; up to 30 tokens) → pick the platform (Scaleo, Affise, Everflow, 1xBet Partners, Melbet or "Another network") → "Connect". The next screen shows what to add to the offer link (for Scaleo &aff_click_id={click_id}), the ready postback lines with the token and a "waiting for the first postback" status that updates by itself. For 1xBet Partners and Melbet enter your CPA rate — those dashboards send no payout.

By hand: "Issue a token by hand" — "Label", "Network", "Network's allowed IPs" (one IP or subnet per line; empty — any address), "Event aliases" (first-deposit=ftd), "Network statuses" (1=approved), "HMAC signing secret" (optional).

The URL is shown once — copy it right away:

https://<your domain>/pb/<TOKEN>

Parameters

GET or POST (form or JSON), names case-insensitive; for the same name the body's value wins. Keitaro, Binom and Voluum names are accepted too.

• click_id (or clickid, subid, sub_id, cid, cnv_id) — required: our {click_id} from the link.
• event (et) — required: lead, reg, ftd (first deposit), dep (deposit), sale or your own (Latin letters, digits, _, up to 32). registration → reg, first_deposit → ftd, deposit / redeposit → dep.
• payout (revenue) — the network's payout, a comma is fine; negative — a correction or chargeback; missing — 0.
• amount (sumdep) — the deposit or order sum, apart from the payout, same currency.
• currency (cur, cnv_currency) — three letters; missing — the tracker currency.
• tx (txid, tid, transaction_id) — the network's conversion ID: tells repeat deposits of one click apart.
• status (cnv_status) — approved / hold / rejected and the usual synonyms (pending, confirmed, declined…); trash and fraud — a rejection with a reason; chargeback / refund — a chargeback; missing — approved. Numeric statuses (1, 2, 3…) — only through the token's "Network statuses" (the Affise template has them set).
• ts (timestamp) — the network's event time, unix or ISO-8601; the money lands on that day.

An unfilled macro ({payout}, [STATUS], %sum%…) counts as missing.

An example for the network:

https://<domain>/pb/<TOKEN>?click_id={subid}&event={goal}&payout={payout}&amount={amount}&currency={currency}&status={status}&tx={transaction_id}

How it counts

• A duplicate is the same click, event and tx with the same status and payout. The same status with another payout or sum is an update. Transitions: hold → approved, hold → rejected, approved → rejected (chargeback), rejected → approved (re-approved, also after "trash" and "fraud"). A conversion never goes back to hold.
• The last postback to arrive wins, as in Keitaro: approved → rejected → approved means the conversion is approved again, a plus on the day it arrived. A postback that matches the conversion's current state changes nothing. If the network sends ts, that sets the order: a postback older than the one already applied doesn't change the conversion.
• A chargeback is a minus on the day it happens: the approval day is not rewritten and totals per click and offer reconcile. A re-approval is a plus on its own day.
• A click's first deposit is marked FTD (both ftd and the first dep); ftd and dep with one tx are one deposit. A repeat deposit without tx can't be told from a repeat — the log asks you to add the transaction id macro.
• A click older than the attribution window (30 days by default, "Tracker settings") doesn't count.
• The payout is converted into the tracker currency at the event day's rate (UTC); no rate yet — the amount is filled in later.
• Click not found — retried after 1, 5 and 30 minutes, then "no click".

The answer

Always 200 "OK" — whether the click exists or not. Over 600 requests a minute per token — 429; a failed write — 503: the network retries and nothing is lost. "Postback log" — the last 100 requests with the result and reason.

HMAC signature

With a secret set: hex HMAC-SHA256 with that secret — in the X-Signature header (a sha256= prefix is fine) or the sig / signature parameter. A wrong signature or an IP outside the list — the request is recorded as rejected.

The signed string, the same for GET and POST:

1. Every query and body parameter (for one name — the body's value), names exactly as sent, except the signature itself (sig / signature); nested JSON values are skipped.
2. Sorted by name, ascending.
3. Name and value percent-encoded per RFC 3986 in UTF-8: only A–Z a–z 0–9 - . _ ~ stay as is, a space → %20.
4. Joined as name=value with &. JSON numbers as their text, true / false lower-case, null empty.

Example: b=x y and a=1+1 → the signed string is a=1%2B1&b=x%20y.