​

CDP conversion forwarding: Meta, TikTok, and the multi-platform hub

• Meta CAPI — a dedicated destination tab for Meta’s Conversions API.
• TikTok Events — the dedicated destination tab for TikTok’s server-side Events API.
• Conversion forwarding — a multi-platform hub covering Meta, Google, TikTok, LinkedIn, Snapchat, Pinterest, and Reddit in one place, with a forward run-history table.

1. Email and phone identifiers are normalized and SHA-256-hashed server-side before they leave Orbit — cleartext PII is never sent to the networks.
2. The access tokens you paste into the dedicated destination tabs are encrypted at rest and never returned by a read — the page shows a “Token set” badge and a write-only input.

​

1. What conversion forwarding does

​

2. Meta CAPI destination

​

Example

curl -X PATCH https://api.orbit.devotel.io/api/v1/cdp/meta-capi-destination \
  -H "Authorization: Bearer $ORBIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "enabled": true,
    "pixel_id": "1234567890",
    "test_event_code": "TEST12345",
    "access_token": "EAAG..."
  }'

​

3. TikTok Events destination

​

Example

curl -X PATCH https://api.orbit.devotel.io/api/v1/cdp/tiktok-events-destination \
  -H "Authorization: Bearer $ORBIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "enabled": true,
    "pixel_code": "C1A2B3C4D5E6F7G8H9",
    "access_token": "ttk..."
  }'

​

4. Google GA4 / Ads in scope

​

5. The conversion-forwarding hub

• GET /api/v1/cdp/conversions/config — every platform’s mapping: enabled, Nango connection id, destination id, event-name mappings, and the last-forward run status.
• PATCH /api/v1/cdp/conversions/config/:platform — update one platform. :platform is one of facebook, google, tiktok, linkedin, snapchat, pinterest, reddit. Only the keys you send are touched.
• GET /api/v1/cdp/conversions/forwards — recent forward runs across all platforms, newest first (bounded retention).
• POST /api/v1/cdp/conversions/forward/:platform — dispatch a batch of conversion events for one platform; each run appends to the history above.

• Destination id — the network-side target: Meta pixel id, Google customer id, TikTok pixel code, or the network equivalent.
• Nango connection id — the connection identifier from the OAuth flow you complete once under the Destinations tab. The hub holds no secrets — it references the connection by id only.
• Event mappings — source → target rows translating your CDP event names to the network’s conversion / action names. Empty means events forward under their original name.

​

The save gate

​

6. Send conversions with hashed user data

curl -X POST https://api.orbit.devotel.io/api/v1/cdp/conversions/forward/facebook \
  -H "Authorization: Bearer $ORBIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "events": [
      {
        "event_name": "Order Completed",
        "event_time": 1726470000,
        "event_id": "ord_9f8e1c",
        "value": 129.99,
        "currency": "USD",
        "order_id": "order_55321",
        "action_source": "website",
        "event_source_url": "https://your-store.example/checkout/confirm",
        "user": {
          "email": "customer@example.com",
          "phone": "+15551234567",
          "external_id": "user_88371",
          "fbc": "fb.1.1726469000.PQe8mV1A...",
          "fbp": "fb.1.1726468000.123456789",
          "ip": "203.0.113.9",
          "user_agent": "Mozilla/5.0 (…) ..."
        }
      }
    ]
  }'

• event_name — the CDP source event name; your stored mappings translate it to the platform’s conversion name.
• event_id — the dedup key the network uses to de-duplicate this server event against a browser-pixel event of the same id. Always send it when a client-side pixel also fires.
• user — at least one matchable identifier is required: email, phone, external_id, a mobile advertising id, or the network click id (fbc, gclid, ttclid, li_fat_id, sc_click_id, pinterest_click_id, rdt_cid). The click + context fields pass through raw because the networks match them unhashed — hash them yourself and matching falls to zero.
• A batch is capped at 1,000 events per request. The network itself only accepts a batch once the platform config is wired (destination_id + nango_connection_id); otherwise the forward returns 409 and the run history records the skip.

​

7. Guard-rails against double-fire

• Event-level dedup — the auto-forward loop claims a deterministic idempotency key per event (scoped to workspace, destination, event name, and the CDP event id) for 48 hours, so a redelivered message or a worker retry resolves to the same key and is skipped rather than re-POSTed. Platform-side, the event_id you attach is the dedup key the network applies between its server events and browser-pixel events.
• Consent-aware suppression — an EU subject who has not granted ad-data consent gets the conversion suppressed outright (no legal basis), while a US state-privacy opt-out is downgraded to Meta Limited Data Use rather than dropped — the forward happens, flagged, instead of vanishing silently.
• Daily volume cap — each workspace’s auto-forward volume is bounded by a per-day cap (a generous platform default; a workspace can lower it from settings) so a runaway event source can’t inflate attribution with a flood of forwards. The guard fails open on dependency degradation — a guard-rail can never silently drop a legitimate forward.

​

8. Role gating

​

See also

• CDP integration console: source and destinations — the outbound event-forwarding half (Google Analytics 4 included)
• CDP segments — build the audiences conversions are attributed against
• CDP tracking plan — declare the conversion event shapes producers send
• CDP event debugger and DLQ — tail the inbound stream that feeds forwarding