Privacy Policy

Google user data

There are two separate Google connections, asked for separately and each optional. An owner can connect a calendar without ever connecting their mail, or the other way round.

How Razar uses Google user data, in short

• What we access:with the owner's permission, their Google Calendar busy times (calendar.freebusy), the calendar events Razar itself creates for their bookings (calendar.events), the ability to send email from their Gmail address (gmail.send), and their Google account's email address (userinfo.email).
• How we use it: only to provide the features the owner turned on: hiding times they are busy from their booking page, adding, moving and removing the calendar event for each booking, sending the emails they write to the customers they choose when they press send, and showing which Google account is connected. Nothing else.
• What we store:the encrypted OAuth tokens, the connected account's email address, the identifier of each event we create, and our own record of emails sent. Busy times are used to work out free slots and never stored. We never read or store mailbox contents.
• Who we share it with:no one. Google user data is not sold, rented, shared with or transferred to any third party, and not used for advertising or to train AI. It is processed only on Razar's own servers and database (our hosting and database providers, who store it for us and do not use it), and disclosed only if the law requires it. The only places it goes are the owner's own Google Calendar and the recipients the owner chooses to email.
• How long we keep it: until the owner disconnects Google or deletes their account, when the tokens are deleted immediately.

Google Calendar

Connecting a Google Calendar is optional. Bookings work without it — we simply cannot see existing commitments or write bookings to a calendar. When an owner does connect one, we request the narrowest scopes that make the feature work:

• calendar.events — to create an event when a customer books, move it when the booking is rescheduled, and delete it when the booking is cancelled.
• calendar.freebusy — to read which time windows are already busy, so those slots are hidden from the public booking page and nobody is double-booked.
• userinfo.email — to show which Google account is connected, so an owner can tell at a glance that it is the right one.

What we read but never store

Availability is read as free/busy windows only — start and end times. We do not receive, and could not display, the titles, descriptions, guests, or locations of existing events. Those windows are used to compute available slots and are never written to our database.

What we store

• Google OAuth access and refresh tokens, encrypted at rest with AES-256-GCM.
• The token expiry time and the list of permissions granted.
• The email address of the connected Google account.
• Which calendar to use — the account's primary calendar.
• For each booking, the identifier of the calendar event we created for it.

What we write to a calendar

One event per booking, containing the customer's name in the title; their name, email address, and any notes they left in the description; the start and end time; and the customer added as a guest. We do not send Google's own invitation emails — the customer receives our confirmation instead.

Gmail

Connecting Gmail is optional and separate from the calendar. It exists so that marketing email an owner sends to their own customers leaves from their own mailbox, with their name on it, rather than from an address their customers do not recognise. Without it, the same messages can be copied out and sent by hand.

• gmail.send — to send a message the owner has written, to the customers the owner has chosen, at the moment the owner presses send. This scope can only send. It cannot read, search, or list anything in a mailbox, and it gives us no access to received mail, drafts, labels, contacts, or history.

We do not read, store, or index the contents of any mailbox — we hold no copy of an owner's inbox because the permission we ask for could not produce one. What we do store is our own record of what was sent: the recipient's email address, the subject and body as rendered, and the time it left. That record exists so an owner can see what went out, and so the same person is not written to twice by accident.

Nothing is ever sent without an owner pressing send. There is no automatic or scheduled sending on this connection, and Razar never sends marketing mail on an owner's behalf without them starting it. Every message carries an unsubscribe link and the business's postal address, and anyone who unsubscribes is excluded from that moment on.

An owner can disconnect Gmail at any time from the Reach out page, which deletes the stored tokens immediately, and can revoke it independently at myaccount.google.com/permissions.

How we protect Google user data

• In transit: every connection between your browser, our servers and Google uses HTTPS (TLS). We never accept or send Google data over an unencrypted connection.
• At rest: OAuth access and refresh tokens are encrypted with AES-256-GCM before they are stored. The encryption key is kept in our hosting provider's secret store, separate from the database and from our source code. The database itself is also encrypted at rest by its provider.
• Tokens stay on our servers. They are used only by our server to call Google on the owner's behalf, and are never sent to a browser, shown in the app, written to logs, or shared with any other service.
• Access: each business owner can see only their own business's data, checked on every request. Within Satya Labs LLC, access to production systems is limited to the company's administrator, and only to operate and secure the service.
• Minimisation: we ask for the narrowest permissions that make each feature work, and calendar availability is read as busy/free times only, never stored.
• Retention and deletion: tokens are deleted the moment an owner disconnects, or when their account is deleted. Nothing read from Google is kept after it has been used.
• If we ever learn that Google user data has been accessed without authorization, we will tell the affected owners and Google promptly.

Limited Use

Razar's use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including its Limited Use requirements. We do not sell this data, use it for advertising, use it to develop, improve or train AI or machine-learning models, or allow humans to read it except where required for security, to comply with the law, or with the owner's explicit permission.

Disconnecting

An owner can disconnect at any time from their calendar settings, which deletes the stored tokens immediately. Access can also be revoked directly at myaccount.google.com/permissions. Events already written to a calendar belong to that calendar and stay there — we no longer have any means of removing them.

Other information we handle

From business owners: name, email address, page handle, and the products, services, hours, and content they publish.

From customers who book: name, email address, the time booked, their timezone, and any notes they choose to add. We hold this on behalf of the business being booked; that business decides what happens to it.

Text messages (SMS)

If a business owner enters their own mobile number in their account settings and agrees to receive texts, Razar uses it to text them about their own account — a new order, a new booking, an enquiry waiting for a reply, or their Google Calendar disconnecting. We record when they agreed. This number is never shown to their customers and is never used to text anyone else. Agreeing is optional, and an owner can remove the number from their account settings at any time, or reply STOP to any text.

No mobile information will be shared with third parties or affiliates for marketing or promotional purposes. Text messaging originator opt-in data and consent will not be shared with any third parties, except with the service providers that deliver the text messages (Twilio and the mobile carriers). The sharing described elsewhere in this policy excludes text messaging originator opt-in data and consent.

The program’s terms, including frequency and how to stop, are in our Terms of Service.

Services we rely on

We share only what each service needs to do its job: Google (calendar sync), Resend (email), Twilio (text messages), Stripe (payments — card details go directly to Stripe and never reach our servers), Cloudinary (images), and our hosting and database providers.

Keeping and deleting data

Bookings are kept so both sides have a record. Calendar tokens are deleted the moment a connection is removed. Owners can ask us to delete their account and its data by writing to privacy@razar.one. Customers who have booked can ask the business they booked with, or contact us directly.

Contact

Questions about this policy go to privacy@razar.one. See also our Terms of Service.