Guest space
The guest space is your company’s own application for the people who stay in your holiday homes. It lives at <company>.guests.majali.app, or at a host of your own verified on the Domains screen, and carries your branding. Guests sign in by email, see their stays and pay for them. You can also place it inside a page of your website. It needs the embeddings and guest space features, together with bookings.
What guests get
- Sign-in by email link. A guest enters their email and receives a link that works once and expires after 15 minutes. The link is confirmed by a click on the page it opens, so a mail scanner that follows links cannot use it up. There is no password.
- Their stays. Upcoming stays, requests waiting for your answer, and history, each with its quote, fees, payment, deposit and refund state, and the arrival details and contact you chose to show. Internal notes, commissions and anything from the CRM never appear.
- Paying. A stay that is confirmed and inside its payment window can be paid from its page, through the payment connectors you set up. A payment shows as paid only once it is confirmed with the provider.
- English and Arabic, on the phone and the laptop. A guest’s session lasts 12 hours, or 30 days when they choose to be remembered; they can sign out at any time.
A booking opens to a guest only through the exact email the booking was made with. A guest whose email matches no booking sees an empty page. The stay links in the emails you already sent lead to the guest space and ask the guest to sign in.
The embedding on your website
Open Settings > Embeddings > Embeddings. One configuration describes one placement of the guest space, in one or more websites. Saving asks for a fresh code, and every change is recorded in the audit log. Its tabs:
| Tab | Settings |
|---|---|
| Configuration | A name, the module (the guest space), the state (Draft, Published, Paused) and the delivery: Standalone, Embedded with standalone recovery, or both. The guest hostname is one of your verified guest hosts. |
| Websites and languages | The exact websites allowed to embed it (https:// addresses, no wildcards), the pages on your website guests return to after signing in, the languages offered and the default one. |
| Appearance | A theme built from your branding: colours, fonts and approved images, each checked. No custom CSS or scripts are accepted. |
| Install | The configuration’s public ID, the installation snippet, the standalone address, and Desktop preview and Mobile preview. |
How to go live:
- Save the configuration as a Draft and open the previews. Nothing is reachable from a website yet.
- Set the state to Published. Publishing is refused until the guest hostname is verified and, for an embedded delivery, at least one website is approved.
- Copy the snippet from the Install tab into your website’s page. How it fits into a page, the events it sends and the sizing rules are in the developer docs at /en/developers/embedding.
- Set the state to Paused to take the placement off the website without deleting anything; set it back to Published to restore it.
Only a published configuration can be shown inside a website, and only by the websites listed. Signing in always happens on the guest space’s own address, never inside the website’s page, then returns the guest to the return page you set. If the embedding is unavailable, the standalone address keeps working.
Guest accounts
Open Settings > Embeddings > Guest accounts. Each row is one guest who verified their email: its public ID, whether it is active, and when it was verified. Accounts are created by the guests themselves, never from this screen, and cannot be deleted here. Switch Active off to stop a guest signing in; switch it on to let them back.
A guest’s email and bookings are personal data: find, export or erase them with One person’s data, and they are part of the full export (see Your data). Erasing a guest ends every session and sign-in link at once.
Booking access
Open Settings > Embeddings > Booking access. Each row gives one verified guest account access to one booking. Guests get it by themselves whenever the booking’s email matches their verified email; this screen is for the cases where it does not, for example a booking taken on the phone with a misspelt address.
- Choose the booking and the guest account. The guest must be active and verified, and neither the guest nor the booking may be erased.
- The guest’s verified email must match the booking’s email. If the booking’s email is wrong, tick Correct the booking email to this verified guest’s email; this needs the permission to change bookings.
- Saving asks for a fresh code. A correction is recorded in the audit log and revokes the access the old email had.
Access is never granted on a name, a phone number, a booking reference or a contact in the CRM: only the verified email.