Hide the Booking Menus, Keep API Booking Working
Closing a door is not the same as closing the road.
Some tenants connect only through the API and have no use for the Search, Quotes and Bookings menus in the portal. The platform can now hide just that menu group for a tenant, while subscriptions and backend booking permissions stay exactly as they were.
Some tenants wire HotelByte into their own systems, and their guests book on their own websites. Their staff have no use for the portal’s Search, Quotes and Bookings menus, which mostly get in the way: when someone books in the portal out of habit, orders end up in two places. The reasonable request is simple. Hide those menus, and do not touch the API.
Until now the only lever available was removing the subscription features behind those menus. The menus did disappear, but backend and API booking went with them, because what the portal showed and what the tenant could actually do hung on the same subscription switch. For a tenant that connects through the API, that meant switching off its bookings as well.
A platform-managed option in the tenant profile hides the booking portal. When it is on, the booking menu group and everything under it disappear from the portal. Routes, subscription features and backend booking authorisation are unchanged, so API booking keeps working. Only the platform can set it, and only on tenants: a value echoed back when a tenant saves its own profile is ignored, and turning the option off brings the menus back.
We did not build a new permission model for this. The option lives in the tenant profile and governs menu presentation only, because it answers a different question: permissions decide whether a tenant can transact, and this option decides what the portal shows. Keeping the two apart lets operations shape the portal around how each customer connects without touching the ability to book.