Platform Integrations

Overview

A platform integration is a paired setup created in one call:

1. A managed browser tag — the SDK loads the Meta Pixel (or Google Ads gtag) and fires it for every tracked event, passing each event's Mythic-generated event uuid as Meta's eventID (or Google's transaction_id).
2. A server destination — the matching meta_capi or google_ads destination sends the same events server-side with the same event uuid.

Because both halves carry the same id, the ad platform collapses each browser + server pair into a single conversion. Dedup is guaranteed by construction — you never handle event ids yourself.

Connect Meta

One endpoint creates both halves. Send the pixel id and (on first connect) a Conversions API system-user token:

POST /client/v1/destinations/integrations/meta

{
  "pixel_id": "123456789012345",
  "capi_token": "EAAx…system-user-token…",
  "event_mapping": { "purchase": "Purchase" },
  "test_event_code": "TEST123",
  "credential_name": "live"
}

The event_mapping merges over sensible defaults ($pageview → PageView, view_item → ViewContent, add_to_cart → AddToCart, begin_checkout → InitiateCheckout, purchase → Purchase, lead → Lead, and more). Any Mythic event not in the mapping is not sent to Meta.

If a meta_capi credential is already stored you can omit capi_token; the token is write-only and never returned. Deliveries use the credential named credential_name (default default) — pass e.g. "live" when the working token is stored under another name. browser_tag: false skips the managed pixel for sites that already run their own — Mythic then only sends CAPI.

Connect Google Ads

Google Ads uses the Data Manager API for the server half, so the OAuth credential must exist first (store it with PUT /credentials/google_ads, or run the OAuth flow via POST /oauth/initiate):

POST /client/v1/destinations/integrations/google_ads

{
  "customer_id": "1234567890",
  "event_mapping": {
    "purchase": {
      "conversion_action": "customers/1234567890/conversionActions/987",
      "conversion_label": "AbC-D_efGh",
      "default_value": 100,
      "currency": "USD"
    }
  }
}

Each event needs a conversion_action (server half). A conversion_label additionally turns on the managed gtag browser tag for that event, with transaction_id defaulted to the event uuid so browser and server sends dedupe. Events without a label are server-only.

Status and disconnect

GET /integrations reports, per platform, which halves are connected and whether the delivery credential is stored:

GET /client/v1/destinations/integrations

{
  "success": true,
  "data": {
    "meta": {
      "platform": "meta",
      "label": "Meta (Facebook)",
      "connected": true,
      "browser_tag": { "tag_id": "…", "enabled": true, "config": { "pixel_id": "123456789012345", "event_mapping": { "purchase": "Purchase" } } },
      "destination": { "id": "…", "action_type": "meta_capi", "enabled": true },
      "has_credential": true
    },
    "google_ads": { "platform": "google_ads", "connected": false, "browser_tag": null, "destination": null, "has_credential": false }
  }
}

Disconnecting (DELETE /integrations/{platform}) detaches the browser tag and removes the managed destination — and the stored credential too, when no other destination of that type remains.

Identity matching

Match rate decides how many conversions a platform can attribute, so both halves send every identifier Mythic knows about — no configuration.

Server half. The Conversions API / Data Manager payload carries SHA-256 hashes of email, phone, first name, last name, external id, city, region, postal code and country, taken from the resolved person — including every email and phone stitched onto that person by identity resolution, so a contact known by a work address in your CRM still matches on a personal address captured by the pixel. It also sends fbp, fbc (restored from the click vault when the click predates the conversion), the client IP and the user agent.

Browser half. The SDK collects identity from identify() traits, person properties ($set), super properties and the properties of the events you capture — form fills included — normalizes it the way each platform expects, and declares it as Meta Advanced Matching / Google Enhanced Conversions before the event it applies to. Learning an email mid-visit re-declares matching so that conversion benefits, and nothing is re-sent while the identity is unchanged.

Values leave the browser hashed by fbevents.js / gtag.js, which is why the SDK hands them over normalized but unhashed — pre-hashing would double-hash and match nothing. Values that cannot match are dropped rather than forwarded: an address with no TLD, a phone under 7 digits, a spelled-out country name.

Consent and existing pixels