Tenant data isolation
Each restaurant receives a separate tenant database. Authenticated application services resolve the current restaurant before opening tenant data, and public agent catalog endpoints never open a restaurant database.
Security at Rosuii
Rosuii is a multi-tenant restaurant platform, but restaurant operational data is not stored as one shared set of tenant rows. Each restaurant tenant is provisioned with its own MySQL database and application requests are resolved into that tenant context.
Last reviewed:
Each restaurant receives a separate tenant database. Authenticated application services resolve the current restaurant before opening tenant data, and public agent catalog endpoints never open a restaurant database.
Panel access uses authenticated sessions. Restaurant roles and granular permissions control operational actions, and account status can be disabled when access should stop.
Restaurant integration keys use an rsk_ secret shown to the owner when created. Rosuii stores a SHA-256 hash for lookup rather than storing the presented raw key in the central key table.
A verified restaurant API key determines the tenant. The caller does not provide a tenant ID that can be changed to request another restaurant's customers, staff, orders or reports.
The public Agent API and read-only MCP server expose product facts, features, pricing and FAQ. They do not provide public tools for restaurant orders, customers, staff, inventory or sales.
Public Agent API, event collection and MCP routes apply endpoint-specific rate limits. MCP requests also validate the browser Origin when one is supplied.
Email [email protected] with a concise description, affected URL or account context and safe reproduction steps. Do not include passwords, live payment credentials or unnecessary customer data. Please give the team reasonable time to investigate before public disclosure.