KNOWLEDGEBASE
XOM

Immersive Data Exchange

2 min read·Article 11 / 24

Immersive Data Exchange covers how content and state move between XOM and systems outside it — other DigiFX platforms, external media sources, and registered client applications. In the platform's own architecture this is the API Bridge Sync subsystem plus a set of bridge components inside the app.

01The bridge subsystem

API Bridge Sync is specified with three responsibilities: external integration, API orchestration, and cross-platform synchronisation. Its documented flow starts with registering an external service in an integration registry, then mapping data fields between the two schemas, then configuring webhooks so the remote system can push events into an event listener network.

Orchestration follows: sync rules define what moves and when, a polling scheduler sets frequency for systems that cannot push, and a merge strategy manager decides what happens when both sides changed the same record. A sync health dashboard reports status, and a resilience controller governs retry behaviour on failure.

02Bridges inside the application

XOM ships several named bridge components rather than one monolithic connector:

  • Media Console bridge — a connector, an authentication module for external API credentials, a configuration module for media sources, and a library browser for the assets it exposes
  • Aware Technology bridge — the connector to XOM's AI subsystem layer
  • Platform bridge — cross-platform content synchronisation, with XOM held as the primary hub rather than a mirror

Alongside these, an advancedProxy Cloud Function handles the harder case of pulling in content that was never designed to be embedded. It fetches a remote page and rewrites its HTML, images, stylesheets, scripts, fonts and video embeds so that every sub-resource routes back through the proxy, with caching and retry in front of it.

03Identity at the boundary

Access across the DigiFX estate is described by a shared authentication and authorisation matrix. XOM appears in it as one of eleven platform entries, with three named trigger conditions:

  1. User session (consumer, creator, or moderator) — grants a session token carrying an anti-abuse risk score used for adaptive moderation
  2. XP, mission and leaderboard writes — rate-limited and validated, granting a write-protected reward wallet nonce so a reward cannot be recorded twice
  3. API access for client applications — requires app registration and API key verification before an app can reach XOM's engagement and content endpoints

The third of these is the entry point that matters for integrators. The matrix also records the policy checks that run before access is granted, including community moderation thresholds and reward entitlement and anti-fraud checks.

Need custom diagnostic analysis?

Contact our support engineers directly to initiate bespoke technical resolution.

CONNECT SUPPORT