Until now a hub client received the raw event payload in whatever shape the producing service happened to emit, with no way to say what it could parse. Two optional query parameters on the connection URL change that. xm_envelope=1 wraps every message in a stable envelope carrying a contract id, the producer, a messageId, a sentAt timestamp and the selected payloadVersion, so you can route on a contract id instead of inferring intent from the payload shape. xm_svc_versions=domain:18,messaging:1 declares the highest payload version you understand per producing service, and the platform then selects the newest variant that is at or below what you asked for.

Neither parameter changes which events reach you: the audience is still derived from the identity in your token. They change the format and the version. A client that declares what it can parse can then be upgraded on its own schedule.

Two details are worth reading before you adopt them. Both Messaging API contracts are envelope-only, so a client that has not opted in never receives them, silently. And the parameters never report an error: a malformed value leaves you with a healthy connection that behaves differently than you intended, so confirm against the first message you receive rather than against a successful connect.

The real-time notifications guide covers the envelope fields, the version selection rules, the full contract catalog, and the reconnect behaviour that decides whether your declaration survives. Interactive explorers also mark which REST operations can publish which contracts, so you can see the link from a call to the message it triggers.

Too much integration time has gone into piecing answers together from support threads, sample projects, and outdated examples. The new portal removes that friction. You can switch between API areas without losing context, copy verified curl and TypeScript snippets, and review rate limits before planning automation or batch operations. The structure was validated against real integration work before release, so the path from first call to production follows the order you actually build in.

The content is organized so each API surface provides a clear introduction to workflows, authentication requirements, rate limits, and recommendations for production use. REST endpoints include embedded interactive explorers that allow you to inspect payloads, verify request shapes, and browse the supported versions of each API. A dedicated versioning section explains how to interpret the api-supported-versions header and how to adopt newer capabilities in a controlled way.

We have also improved the onboarding flow. The authentication guide now describes the supported flow in detail, based on JWT bearer tokens issued by the authentication endpoint. It includes guidance on device headers, access token lifetime, drift tolerance, and the rolling refresh token window. API keys are not available to partners today, so the guides walk you through provisioning an integration user and maintaining a stable refresh loop. The Webhooks quickstart includes examples that work with tools like ngrok. The Messaging documentation covers templated content on WhatsApp. The Storage section provides a complete TUS upload sequence with checksum validation and signed download guidance. Common pitfalls have been documented to reduce the guesswork that often slows early development.

A new changelog section provides tagged releases with RSS support. The homepage now includes a live status indicator sourced from our Statuspage feed so teams can see current availability of the Core API, Messaging endpoints, and other surfaces before retrying operations. Improved transparency has been a recurring request and this is an important step forward.

This release marks the foundation of our public documentation. Further improvements will follow. If you discover issues or gaps, contact us at support@xmreality.com and we will address them in upcoming updates.

Thank you to everyone involved in building this release. In the coming weeks we will continue to expand the portal with more sample code, deployment scenarios, infrastructure examples, and guidance for observability and monitoring. Our aim is to ensure the documentation grows with the platform and remains a reliable resource for all integration teams.