Architecture overview

This page gives a simplified, public view of how HyoNova is built, so you can reason about data flow, security and future integrations. It leaves out hosting details on purpose.

The four parts#

How a request flows#

1. You open HyoNova in the browser. The web app loads over HTTPS from https://app.hyonova.com.
2. You sign in. The platform checks your email and password and gives the browser a secure session cookie. See Authentication.
3. You open company data. The browser asks the API. The API checks your role and permissions, then reads the data inside a transaction bound to your company, where the database enforces isolation.
4. You enter an office world. The browser connects to the real-time service, which shares presence and movement with the other people in the same office and enforces world permissions such as who may enter a room.
5. You talk or meet. For spatial voice, calls and meetings, the platform checks that you may join and hands the browser a short-lived permission for the media service. Audio and video then flow between the browser and the media service, encrypted in transit.
6. Something needs to happen later. Actions such as sending an invitation email, sending a Mail campaign in batches or delivering a webhook are placed on a queue and handled by background jobs, so the page — or your API call — does not wait for them.

Design principles#

• The server decides. Permissions, plan limits, room capacity, seat use and who can hear whom in spatial voice are all enforced by the platform, not by the browser.
• Company isolation in the database. Isolation between companies does not depend only on application code; database rules enforce it.
• One source of truth. The office and the company workspace read the same data. A task you create from your desk in the office is the same task in the dashboard.
• Some things stay local. The personal scratchpad, office builder drafts and your world preferences are stored in your browser, not on the platform.

What this means for integrations#

• The public interface today is the Mail API: your servers send email with an API key, and HyoNova calls your endpoint with signed webhooks. Both follow API conventions.
• The API between the browser and the platform is internal and not supported for integrations. A general public API is planned. See Developers.

Show technical details

• The 3D office uses Babylon.js on WebGL. It needs a desktop browser with WebGL enabled and a screen at least 600 pixels wide.
• The real-time service and the API share the same company isolation and permission model.
• Background jobs are driven by an event outbox: a change and the event that describes it are stored together, then processed by workers.
• The media service is LiveKit, provided and connected by HyoNova. Email delivery, including Hyo Mail, uses Amazon SES. Neither is configured by customers; for Mail, you verify your own sending domain with DNS records.
• A Mail campaign is frozen when it is sent: its content, sender and recipient list are fixed, and background workers send it in batches within the company's Mail credits — one credit per recipient email — and sending rate.