Web

Send and receive journey events over postMessage in a web iframe.

This page shows the CG specific envelope and events. For the underlying window.postMessage API itself, see MDN: Window.postMessage().

Prerequisites

The journey must already be embedded per Web Embedding (iframe), including its sandbox/CSP requirements.

Messaging depends on the iframe loading and its scripts executing. A sandboxed iframe that blocks script execution, or a CSP that blocks the frame from loading, will prevent messaging as a direct consequence.

Listening for events from the journey

<iframe id="cg-journey" src="https://xcj.xcover.com/acme-travel/en/?country=AU"></iframe>

<script>
  const JOURNEY_ORIGIN = 'https://xcj.xcover.com'; // use the sandbox origin in non-prod

  window.addEventListener('message', (event) => {
    // Always verify the origin before trusting the payload.
    if (event.origin !== JOURNEY_ORIGIN) return;

    const { source, type, payload } = event.data ?? {};
    if (source !== 'xcover-journeys') return;

    switch (type) {
      case 'CG_JOURNEY_READY':
        console.log('Journey mounted and ready to receive messages');
        break;
      case 'CG_JOURNEY_COMPLETE':
        console.log('Journey finished:', payload.outcome, payload.policy_id);
        break;
      // ...handle other event types as needed
    }
  });
</script>

Sending events into the journey

<script>
  const journeyFrame = document.getElementById('cg-journey');
  const JOURNEY_ORIGIN = 'https://xcj.xcover.com';

  function sendToJourney(type, payload = {}) {
    journeyFrame.contentWindow.postMessage(
      { source: 'xcover-journeys', type, payload },
      JOURNEY_ORIGIN,
    );
  }

  // Example: ask the journey to hide itself
  sendToJourney('CG_JOURNEY_HIDE');
</script>

Origin and security requirements

postMessage has no built-in authentication. Origin checking is the entire security model. Both sides must get this right.

The journey only accepts inbound messages from an explicit allowlist of trusted origins, configured per environment during onboarding. Messages from any other origin are dropped, not queued, not errored, silently discarded.

Always check event.origin before trusting event.data, as shown above. Never branch on message content alone.

Requirement	Detail
What to provide	The exact origin(s) (scheme, host, and port) your page is served from, for each environment you integrate against (sandbox and production).
Matching	Exact string match against event.origin. No wildcard or subdomain matching: https://acme.com will not match a message sent from https://www.acme.com.
When to update it	Any time your integration domain changes (new environment, domain migration, added subdomain). Contact your integration manager before the change ships, not after.

If the journey's trusted-origin configuration is empty or missing for your environment, the journey will not process any inbound messages. This fails closed, not open.

For Outbound target origin, the journey sends outbound events to a single configured origin per environment, set up during onboarding alongside the trusted-origin allowlist above. You do not configure this yourself.