Server-Side Conversion Relay

Those scripts don't just fire a conversion — they report page_location, page_title, and page_referrer back to Google/Meta ALONGSIDE the click id. That hands the ad platform a direct comparison between the URL your campaign's Final URL points at (the safe page) and the URL that just reported a conversion (the money page). That mismatch is the single strongest piece of cloaking evidence there is — and you'd be volunteering it yourself, in the platform's own reporting.

The correct path is server-to-server: Meta's Conversions API and Google Ads' UploadClickConversions are both real-time APIs — "offline conversion import" describes the ROUTE (a server call, not a browser), not a batch schedule. Nothing about using them is slow or delayed. We already store the gclid/fbclid for every click that passes through a stream, so we can do this server-side step for you.

If you're promoting someone else's offer — you don't own the money site, can't edit it, and have no way to add a tag to it — this is your path. It uses the same network-postback mechanism every affiliate network already supports:

1. Turn on Append Conversion Token on the stream (off by default, under Filtering) so we append our own click identifier to the visitor's outgoing URL — it then travels with the click all the way to the offer.
2. The visitor converts on the money site. We never touch that page at any point.
3. The affiliate network fires its own server-to-server postback — to a URL YOU configure once in that network's dashboard.
4. We resolve the click id in that postback back to its stored gclid/fbclid and forward it.

Open a stream's Conversions tab. Every stream gets its own unique postback URL and its own unique click-id parameter to use as the network's subid macro — these are secrets, treat them like a password (see the security note below).

https://the-network.example.com/click?offer_id=123&subid={click_id}

Replace {click_id} with whatever macro YOUR network uses for its own subid passthrough (common names: subid, s1, aff_sub, clickid) — it just needs to carry our click id through to the postback unchanged.

In the network's postback/pixel settings, use their macros for whichever fields they support — below is a worked example against a typical network's macro set:

https://cloakingx.com/api/pb/8f2c1a9e4b7d6053a1e2f9c8d4b6a710e5f3c2b1a9d8e7f6?subid={subid}&payout={payout}&status={status}

The parameter NAMES (subid, payout, status above) are configurable per stream in the Conversions tab — set them to match whatever your specific network actually sends. Most networks only fire this once a sale is already confirmed, so leaving the status parameter blank (the default) treats every postback as an approved conversion.

In Settings → Conversion Destinations, add your Meta System User access token and Pixel id once (account-wide — reused across every stream), then enable Meta on each stream that should forward to it. See the platform-by-platform section below for Google.

Same relay, same URL — call it directly from YOUR OWN server (never from client-side JavaScript, which would expose your postback secret to every visitor's browser) once a conversion happens, using the click id that's already sitting in the money page's own landing URL assubid:

curl -X POST "https://cloakingx.com/api/pb/<your-postback-token>" \
  -H "Content-Type: application/json" \
  -d '{"subid":"<the click id from the landing URL>","payout":"49.00"}'

Fully working. You need a Meta Pixel/Dataset id and a System User access token with permission to send events to it (Events Manager → Settings → Conversions API → Generate access token). We build the fbc parameter for you from the stored fbclid — no snippet, no cookie, nothing on the money page.

We deliberately do NOT integrate the Google Ads API directly for this — that would require applying for a Google developer token, which the account owner is still weighing (see the callout below). Instead, Google conversions leave this system one of two ways:

• Your own server-side GTM (recommended if you run one) — enable the "sGTM" destination and point it at your container's endpoint URL. We POST the resolved conversion (gclid, value, currency, timestamp) there; your own GTM Google Ads tag takes it from there.
• Scheduled-upload CSV feed — if you don't run sGTM, every stream also exposes a CSV feed URL in the Google Ads "Scheduled uploads" format (Google Click ID, Conversion Name, Conversion Time, Conversion Value, Conversion Currency). Paste that URL into Google Ads' Uploads page and set a fetch schedule.

The postback URL is necessarily public — a network's server has to be able to reach it. Its security comes entirely from the long random token in the URL itself, not from IP allowlisting (network postback source IPs aren't predictable enough to allowlist). Don't paste it anywhere public, don't call it from client-side JavaScript, and don't reuse it across unrelated streams.

If you'd rather call Meta's Conversions API or Google's UploadClickConversions yourself, you don't need this relay at all — the stored gclid/fbclid are visible on every click in your Reports tab (and via the API), and you can wire your own server-side integration directly. This relay exists purely to save you from having to build that integration yourself — it does nothing you couldn't do with the raw click data on your own.