Documentation Integrations

Integrations overview

Integrations connect the canonical event pipeline to sources and destinations without putting platform-specific behavior into shared Node code.

Each integration is a self-contained module. It owns its manifests, configuration rules, translators, handlers, and other platform behavior. Shared routing and dispatch remain generic.

Catalog versus runtime

The two sides have different responsibilities:

  • The System catalog publishes module metadata, releases, checksums, and compatibility requirements.
  • The Node runtime installs and validates module packages, stores the Node-side configuration, compiles hot-path-safe integration config, and executes the module.
  • The Console lets your browser configure the connected Node and observe the result.

The catalog does not process your marketing events. Runtime events and customer data remain on your Node until an enabled handler forwards the fields required by its destination.

Canonical-first forwarding

Inbound browser events and webhooks are translated before the shared pipeline runs. During Forwarding, each active outbound handler transforms the canonical event into its platform format.

This keeps a Meta-specific field rule inside the Meta module, a GA4 mapping inside the GA4 module, and shared dispatch independent of either platform.

Read The canonical event payload for the event contract those handlers receive.

Deploy and configure a module

In the Console:

  1. Open Integrations.
  2. Select DEPLOY NEW MODULE.
  3. Choose the source or destination you want to connect.
  4. If the catalog module is installable and compatible with your Node, select Install Module.
  5. Open its configuration, enter the required platform credentials and identifiers, enable it, and save.
  6. Trigger a fresh test event.
  7. Confirm the event in the Console, then confirm receipt in the destination platform.

Installed and active are different states. Installation places compatible module code on the Node; activation and valid configuration determine whether it participates at runtime.

The exact configuration fields depend on the module. Keep credentials out of screenshots, public tickets, page source, and GTM unless a field is explicitly designed as a browser ingestion token.

The GTM source

Google Tag Manager uses the approved Supreme Tracking Event Core template to call the Loader's window.supremeSend. The Node then normalizes the browser envelope like any other source.

Follow Connect Google Tag Manager for the current template behavior and trigger workflow.

Verify forwarding

Use two checkpoints:

  1. Console event: proves the Node accepted and persisted the event.
  2. Destination receipt: proves that an active handler built and delivered a payload the platform accepted.

If the first checkpoint fails, verify your first event. If the first passes and the second fails, focus on the module and destination.

If an active integration receives nothing

Check:

  • The module is installed on this Node and its release is compatible.
  • The integration is enabled, not only installed.
  • Required identifiers and platform credentials are present and valid.
  • A fresh canonical event reaches the Node with the fields the handler needs.
  • The Node compiled the current integration configuration after the latest change.
  • The destination's test or diagnostics view is using the correct account, property, pixel, or stream.
  • Node logs show whether Forwarding attempted the handler and returned an error.

Do not bypass the canonical pipeline with destination-specific logic in shared ingestion code. Fix source mapping in its translator or destination mapping in its self-contained module.