Skip to content
Newv6.18.0Generated values for buyer deliveries, a safer Google Sheet connection, and a post log filter step that explains itself.Read the changelog
Conversions & postbacks

Pay your sources the moment the buyer confirms.

A CPA lead sells as pending and books nothing. Days later the buyer’s postback confirms it, the sale flips to sold, and the payout fires out to the source that sent it — without anyone reconciling a spreadsheet.

Start Free Trial
Book a Demo
Pending → sold on confirmation
Resolution trace on every send
HMAC-signed
Postback configuration with event triggers, rule conditions and delivery status
The CPA loop

The conversion lands late. The money still lands right.

A CPA buyer does not owe you anything the moment you deliver, so Datahubb books nothing: the sale is pending, source payout is zero, and no revenue is claimed. When the confirmation postback arrives — six days, three weeks — the sale flips to sold, the revenue and payout entries fire, and your source is told it earned. If the buyer declines instead, the sale closes with nothing to unwind.

  • No revenue and no source payout booked until the buyer confirms
  • The revenue and payout pair fires exactly once, even if the postback repeats
  • A per-buyer confirmation window closes out anything that never converts
CPA lead · #48213pending
Delivered to CPA buyer
sale pending · source payout $0
Buyer confirms — 6 days later
event=lead · status=accepted · payout=38.00
Pending sale flips to sold
revenue + payout booked, once
Outbound postback fires
lead_sold → traffic source
no revenue booked until confirmation
Matching & the trace

Every conversion is matched to a record, or refused.

An inbound postback carries one id, and what that id means depends on the event: a click conversion carries the click’s id, a lead confirmation carries the lead id and the buyer, a call carries the call id, an exit offer carries the lead’s external id. Each one is looked up against the record it claims to be about. An id that matches nothing is refused outright — no guessing, no orphan row, no revenue attached to a lead nobody can name.

  • The click id ties the conversion back to the click, the source, and the lead it produced
  • A repeat conversion on the same click and buyer is marked duplicate, not paid twice
  • The resolution trace names every config that fired, skipped, or was suppressed — and why
Postback reconinbound
GET/postback
event=cpc
transaction_id=a1f9c3e2-…-8b
payout=4.50
matched to click a1f9c3e2
Reconciled+$4.50
Postback engine

Inbound, outbound, and the accounting in between

Conversions arrive from your buyers and networks. Postbacks go out to your sources on the events they care about. The ledger stays true across both.

One inbound URL, six kinds of outcome

Buyers, networks, call trackers and ad servers all report to the same endpoint on your domain: cpc, cpl, cpa, ppc, exit and lead. The event tells Datahubb which record to go find.

Pending until the buyer says otherwise

A CPA sale books nothing at delivery. On an accepted postback it flips to sold and the ledgers fire; on a rejected one it closes with nothing to reverse, because nothing was ever booked.

Outbound on the events you pick

Each source gets its own configs — its own URL, method, body, headers and secret — subscribed to the events it cares about: lead sold, lead rejected, click converted, call converted, exit converted.

Gated before it fires, not after

Campaign and buyer scopes, a minimum payout, click-type filters, and AND/OR rule groups. If no primary config matches, a fallback tier fires instead — so a source is never left with silence.

Tokens that survive contact with real data

Build the URL or JSON body from tokens like {{event.payout}}, with transformer chains for phone, date, case and encoding. A missing key resolves to empty rather than shipping a broken URL.

Affiliates can wire their own pixel

A traffic source can point a Meta CAPI postback at their own pixel through a structured form — pixel id, event, user-data mapping — without you hand-authoring a URL and JSON body for them.

Signed sends

Your partner can prove it came from you.

Anyone can post to a URL. Give a config a signing secret and every outbound send is signed with HMAC-SHA256 over the method, the URL and the body, and carries the signature, the algorithm and the version as headers. Your partner recomputes the signature with the shared secret and drops anything that does not match — which is what makes a postback safe to act on financially.

  • Signature computed over method, URL and body — not just the payload
  • Algorithm and version sent as headers, so the check can be verified and rolled forward
  • Every send is logged with its URL, headers, response status and body
Outbound postbackhmac-sha256
X-DataHubb-Signature
b64(hmac(secret, …))
X-DataHubb-Signature-Alg
hmac-sha256
X-DataHubb-Signature-Version
v1
signed over METHOD · URL · BODY
FAQ

Frequently asked questions

That is the normal case, and the whole reason this exists. The sale sits pending, earning nothing, until the buyer’s postback lands. Each CPA buyer has its own confirmation window — 30 days by default, anywhere from 1 to 365 — and a nightly job closes out pending sales that pass it, so nothing hangs open forever.

No, deliberately. A CPA lead books zero revenue and zero source payout at delivery — the ping quotes what the source would earn, the post returns nothing, and only the confirmation books the realized amount. The alternative is phantom revenue: counting money at delivery and reversing it a week later when the buyer declines.

The flip from pending to sold is status-guarded, so the revenue and payout pair fires exactly once per lead and buyer. A repeat postback is written to the incoming log for traceability, but it does not re-book the ledgers and does not re-fire the outbound postback to your source. Click conversions work the same way — a second conversion on the same click and buyer is flagged as a duplicate rather than paid again, unless you have explicitly allowed duplicates for that buyer.

Open the resolution trace. It lists every config that was a candidate and names the decision on each one — matched, skipped, or suppressed because a primary config already fired. A skip carries its reason: the config was not subscribed to that event, the click type did not match, the payout was under the minimum, the campaign or buyer was outside its scope, or a rule group failed. The outgoing log then holds the URL, headers, response status and body of what was actually sent.

Yes. Give the config a signing secret and every send carries an HMAC-SHA256 signature over the method, the URL and the body, in three headers. Your partner recomputes it with the shared secret. If it does not match, the call did not come from you.

No, and the difference shows up in your reports. A rejected CPA lead never realized revenue — there is nothing to reverse and no clawback entry. A return is a sale that did book and is later clawed back, which reverses the ledger pair. They are stored and reported as separate outcomes, so a CPA decline never inflates your return rate.

They can, within limits. A traffic source signs in and sees only the configs pointed at them, and can create and edit their own. What they cannot see is the admin side of the data: buyer names appear as ids, and revenue, profit and the buyer token namespace are stripped out of the token picker and rejected if someone tries to send them anyway. The server enforces that, not the screen.

Stop chasing conversions you already earned.

Start your 14-day trial. Full platform access. Card required, no charge if you cancel during the trial.

Start Free Trial
Book a Demo