How SunTatva is built (architecture)

System overview · Updated 2026-10-25

This page explains, in plain words first and then technically, how a sign-in becomes a working hotel screen. Knowing it helps you understand why you pick a group and a property before anything opens, and why one hotel never sees another hotel's data.

The path from login to a screen

1. You log in at the SunAuth portal with your username and password.
2. SunAuth checks you and gives your browser a signed pass (a token) that says who you are.
3. You choose an app and a group on the landing page. SunAuth issues a second token for that app and group. This token also tells the app which database belongs to the group.
4. You click a property. The portal hands the token to the app (SunPMS), together with the id of the property you chose.
5. Every request the app sends to its server carries the token and the active property id, so the server knows the user, the group database and the property.

Key ideas

• Central database and group databases. One central PostgreSQL database holds accounts, groups, property mapping, licences and the support desk. Each group also gets its own PostgreSQL database per app (for example one for SunPMS, one for SunPOS). Nothing is shared between groups.
• The token carries the database. The token SunAuth issues for a group contains the connection to that group's database, so the servers need no per-hotel configuration.
• Property id header. Inside a group, one request is always about one property. The app sends the property id (the PropertyID header) with every request.
• Realtime. The server pushes changes to open screens (for example a new online reservation or a night audit finishing) over SignalR, so the calendar and notifications update without a refresh. The POS kitchen screen, SunHardware devices, SunParking and the support chat use the same kind of push channel.
• Apps talking to each other. Linked apps exchange information in two ways: room charges, parking and hardware use direct calls between the servers, and team chat uses a message queue between them (SunComm). A chat message to a person in SunParking or SunPOS is saved first in the sender's database, then sent in the background with a short-lived SunAuth service token, and applied once by the receiver. Both apps must be linked, belong to the same owner and have the licence Cross-app Chat. See Communication.
• Licences. Licences are stored centrally per property. Servers ask SunAuth what the property has (the answer is remembered for about five minutes; if SunAuth cannot be reached the check passes so the hotel keeps working). Licensed features are protected on the server and hidden in the screen.
• Provisioning. When you create a group, SunAuth asks the database service to create the group's database, run the setup script and seed the first property. This can take a minute or two (the portal waits up to three minutes).

Development ports (for installers and support)

Production uses normal web addresses behind HTTPS. The login hand-off cookie works only when the apps share one root domain.

Messages you may see

Tips and FAQ

• Q: Why do I log in at one address and work at another? A: The portal (SunAuth) checks who you are and hands you over to SunPMS with a short-lived pass; SunPMS then uses its own address.
• Q: Where is my hotel's data kept? A: Each group has its own database; nothing is shared between groups.
• Q: Why was I signed out after an update? A: SunPMS signs everyone out when its version changes (Log out).