This page covers the programmatic surface a developer works against when building interactive content for XOM. Today that surface is a container framework plus a registered-application access path; a product-specific public API is not present in the reviewed codebase.
01The container framework
XOM's extension point for interactive content is the container system. A routing component reads a post record from Realtime Database, extracts its type, metadata and URL, and lazy-loads one of twenty-seven-plus container modules organised into six families:
| Family | Modules | |---|---| | Collaborative | documents, messaging, live polls, multiplayer | | Dynamic | streaming, podcast, galleries, dimensional, artificial | | Elements | gamification, quizzes, surveys, animation, blockchain | | External | embedded, interactive, standard | | Intelligent | content analysis, experience, recommendation, sentiment | | Programmable | applications, assistants, code editors, digital tools, visualization |
Two families matter most for interactive work. The external/interactive container reads an interactive node from the post record, expects a URL and an optional title, and renders the third-party experience in place. The programmable family is where custom micro-applications, in-platform code editors, utility tools and data visualisation engines live.
Because CSS module class names are hashed at build time, stable DOM targeting inside these containers is done with data-* attributes rather than class selectors. That matters for anyone scripting against the rendered output.
02Endpoints in the codebase
The live and broadcast side of the platform defines a small set of HTTP routes: stream read and write, a stream existence check, chat message read and write, a chat highlight action, viewer tracking, and a stream status check.
One architectural constraint applies to all of them. XOM builds with Next.js static export, which means no server-side rendering and no middleware; server-side behaviour is expected to run in Firebase Cloud Functions rather than in Next.js route handlers. Confirm which of these routes is reachable in the deployed build before documenting them as a public API.
03Access for client applications
The shared platform authentication matrix records XOM's third condition for granting access as "API access for client apps": the application registration is confirmed and its API key verified before the app can reach XOM's engagement and content endpoints. Two policy checks are specified as running at that boundary — reward entitlement logic and anti-fraud routines before any account is credited — and moderator-scoped tooling is issued with automatic audit stamps on every action.