Privacy Policy

1. Information We Collect

We collect the information below, either because you give it to us directly, because a customer submits it when making a booking, or because it is generated as you use the Service.

• Provider account details: your name and email address, taken either from Google sign in or from an email and password sign up, together with your business profile, services, staff members, opening hours and settings.
• Booking details submitted by customers: name, email address, phone number, the service and staff member chosen, the date and time, and any note added to the booking.
• Billing details for paid plans. Card payments are processed by Stripe under its own privacy policy.
• Messaging identifiers, such as a LINE user identifier, when a customer chooses to receive booking messages through LINE.
• Google account information and Google Calendar information, when a provider signs in with Google or connects Google Calendar. Section 3 describes this in full.
• Standard technical request information, such as IP address and browser user agent, which our hosting provider processes in order to deliver and protect the Service.

2. How We Use Information

We use personal information only for the purposes listed below.

• To run booking pages, calculate available times, and create, change and cancel bookings.
• To send booking confirmations, reminders and change notices to customers and providers through LINE and email.
• To keep a connected Google Calendar in step with bookings, and to avoid offering a time that the provider has already committed elsewhere in that calendar.
• To manage subscriptions and process payments for paid plans.
• To answer support enquiries and to keep the Service secure, reliable and working as intended.
• We do not use personal information for advertising, ad targeting or profiling, and we do not use Google user data for any purpose other than providing the calendar and sign in features you asked for.

3. Google User Data

Google user data reaches Yoyaku-suru in two ways: when a provider signs in with Google, and when a provider chooses to connect Google Calendar. Connecting Google Calendar is optional and the Service works fully without it. This section describes exactly what we access, why we access it, and what we keep.

• Sign in with Google. When a provider signs in with a Google account, we receive that account's email address and display name, which we use to create and identify the account. We do not request or use a Google profile picture.
• Calendar authorisation scopes. When a provider connects Google Calendar we request exactly two scopes: https://www.googleapis.com/auth/calendar.events, which lets us create, update, delete and list calendar events, and https://www.googleapis.com/auth/userinfo.email, which lets us show which Google account is connected. We do not request access to Gmail, Drive, Contacts or any other Google service.
• Why this access is needed. The calendar events scope is needed for two things: to write each confirmed booking into the provider's calendar so it appears alongside their other commitments, and to read the times that are already taken in that calendar so the booking page does not offer a slot the provider is not free for.
• What we read. When we list existing events, we ask Google for only these fields: the event identifier, the event title, the start and end times, the event status, the free or busy setting, and the private markers that Yoyaku-suru itself added. This means we do read the titles of the provider's existing calendar events, not only their busy time ranges. We do not request event descriptions, attendees, locations, organisers, meeting links or attachments.
• Where event titles appear. Titles of a provider's existing events are shown only in that provider's own dashboard schedule, so that the provider can see their day in one place. They are never shown to booking customers and never shown to another business. A provider can switch off the display of these details in their settings, in which case the titles are removed on our server before the schedule is sent to the browser.
• What we write to the calendar. For each booking we create one event in the connected calendar. It is titled with the service name and the customer's name, and its description contains the service, the customer's name, phone number and email address, and the booking reference. The customer is added as an attendee when they provided an email address, and we set Google's notification option so that Google does not email the customer; Yoyaku-suru sends its own confirmations instead. We also add private markers identifying the event as one we created, and we update or delete that event when the booking is changed or cancelled.
• What we store. In our database we keep the Google access token and refresh token, the token expiry, the scope string Google granted, the email address of the connected Google account, the identifier of the calendar chosen for sync, the sync status, and the identifiers of the calendar events that we ourselves created.
• What we never store. No content from the provider's Google Calendar is written to our database. Event titles and times that we read from Google are held in memory only for as long as it takes to answer the request that displays the schedule, and are then discarded.

4. Google API Services User Data Policy

Yoyaku-suru's use and transfer of information received from Google APIs to any other app will adhere to the Google API Services User Data Policy, including the Limited Use requirements. We use Google user data only to provide and improve the user facing features described in section 3, we do not transfer it except as described in section 5, we do not use it for advertising, and we do not use it to develop or train generalised artificial intelligence or machine learning models.

Read the Google API Services User Data Policy

5. How We Share, Transfer and Disclose Information

We do not sell personal information. We share it only with the service providers listed below, each of which processes it on our behalf, under contract, and only in order to provide its service to us, and in the limited legal situations described at the end of this section.

• Google LLC. Google is both the source and the destination of calendar data. We send requests to Google's APIs to exchange and refresh authorisation tokens, to create, update, delete and list calendar events, and to ask Google to revoke an authorisation when a provider disconnects.
• Cloudflare, Inc. Hosting and network. Yoyaku-suru runs on Cloudflare Workers and is served through Cloudflare's edge network, so every request, including the requests we make to Google, passes through Cloudflare infrastructure. This is necessary in order to run the Service at all.
• Supabase Inc. Database and authentication, hosted in the Tokyo region (ap-northeast-1). This is where accounts, bookings, the Google authorisation tokens, the connected Google account email address, the granted scope, the chosen calendar identifier and the identifiers of the events we created are stored. This is necessary in order to store your data and to sign you in.
• Railway Corp. Reverse proxy carrying authentication traffic between the browser and our authentication service. Sign in identity information passes through it in transit. Google Calendar access tokens and refresh tokens never pass through it.
• Novu Inc. and Infobip. Notification orchestration and delivery. They receive a provider's name and email address, which may have originated from Google sign in, so that notification emails can be delivered. No Google Calendar data of any kind is sent to them.
• The business you booked with. Booking details submitted on a provider's booking page are visible to that provider and to their confirmed team members. Google Calendar information belonging to a provider is visible only within that provider's own business, never to another business and never to booking customers.
• Stripe and LINE receive no Google user data. Stripe receives only the account, customer and payment fields needed to bill a subscription. LINE (LY Corporation) receives only booking messages and LINE identity information.
• We do not send any user data, Google or otherwise, to any artificial intelligence or large language model provider. The Service uses no such provider, and Google user data is never used to develop, improve or train any artificial intelligence or machine learning model.
• We do not sell Google user data, do not share or license it to data brokers or information resellers, do not use it for advertising or personalised advertising, and do not use it to determine creditworthiness or for any lending purpose.
• Legal authorities. We may disclose information where we are required to do so by applicable law, regulation, legal process or an enforceable government request, or where disclosure is necessary to investigate or prevent fraud, to enforce our terms, or to protect the rights, property or safety of our users or the public.
• Business transfers. If Codama is involved in a merger, acquisition, reorganisation or sale of assets, personal information may be transferred to the acquiring entity. We will require that entity to handle the information under a policy no less protective than this one, and we will inform affected users before their information becomes subject to a different policy.

6. How We Protect Your Information

The measures below are the ones we actually operate. We describe them specifically rather than in general terms so that you can judge them for yourself.

• Encryption in transit. All traffic between browsers, our servers and Google's APIs is carried over HTTPS with TLS. Requests arriving on alternative hostnames are redirected to the canonical secure address.
• Storage. Our database is hosted on Supabase, which provides platform level encryption of stored data at rest. Access to the stored Google authorisation tokens is restricted at the database level, as described in the next two points.
• Tenant isolation. Every table holding business data is protected by PostgreSQL row level security and scoped to a single business, so one business can never read another business's records. The row that holds a business's Google Calendar authorisation is readable only by the owner of that business and by its confirmed team members, and has never been made readable by the public, unauthenticated database role.
• Least privilege. The application uses a restricted public key in the browser and a separate elevated key only in server side code, which is never sent to the browser or included in the client bundle. The public, unauthenticated database role has no access at all to the tables holding business account records or staff records, and can read only the tables needed to draw a public booking page, such as services and opening hours.
• Credentials are kept out of logs. Google access tokens and refresh tokens are never written to application logs.
• Authorisation integrity checks. If an authorisation comes back from Google without the calendar events scope, it is rejected before anything is written to our database. If a token refresh comes back without that scope, calendar sync is switched off for that business and the reason is recorded.
• Secret management. Production credentials, including our Google OAuth client secret, are held as Cloudflare Worker secrets and are not kept in our source code repository.
• Access control. Dashboard access to a business is limited to its owner and manager roles. The application has no platform wide administrator role that can read across businesses.
• No method of transmission or storage is completely secure, and we cannot guarantee absolute security. If you believe your account or your calendar connection has been compromised, contact us at support@yoyaku-suru.com.

7. Retention, Disconnecting Google Calendar and Deletion

You stay in control of the Google Calendar connection and of your data.

• Disconnecting Google Calendar. A provider can disconnect Google Calendar at any time from the dashboard. When they do, we call Google's token revocation endpoint to ask Google to revoke the authorisation, and we delete the record holding the access token, the refresh token, the granted scope, the connected Google account email address and the calendar identifier from our database.
• Revocation is requested on a best effort basis. Because the request to Google can fail for reasons outside our control, we delete our copy of the credentials in any case. We also recommend that you review and remove Yoyaku-suru's access in your Google Account at https://myaccount.google.com/permissions.
• After disconnecting, we no longer read the calendar and no longer write bookings to it. Events that Yoyaku-suru created earlier remain in the provider's own Google Calendar; they are the provider's to keep or delete.
• Deleting your account and data. Yoyaku-suru does not currently offer a self service delete control in the dashboard. To have your account and its associated data deleted, write to support@yoyaku-suru.com from the address on the account and we will carry out the deletion and confirm when it is done.
• How long we keep information. We commit to keeping personal information only for as long as it is needed to provide the Service to you and to meet our legal, tax and accounting obligations. Booking records are kept while the business account remains open, and are removed when we act on a deletion request or when the account is closed.
• If you booked through a business that uses Yoyaku-suru, that business decides what booking records to keep, so please contact the business first. We will support the business in acting on your request.

8. Your Rights

Subject to applicable law, you have the following rights over your personal information.

• You may ask us for access to the personal information we hold about you, for correction of information that is wrong or out of date, for deletion, and for restriction of or objection to certain processing. Where the law provides for it, you may also ask for a copy of your information in a portable form.
• You may withdraw your consent to the Google Calendar connection at any time, either by disconnecting it in the dashboard or by removing Yoyaku-suru's access in your Google Account at https://myaccount.google.com/permissions.
• To exercise any of these rights, write to support@yoyaku-suru.com. We will ask you to verify that you control the account or email address concerned before we act.
• If you booked an appointment with a business that uses Yoyaku-suru, that business decides how your booking information is used. Contact the business first. You may also contact us and we will pass the request on and assist.

9. Contact Us

Yoyaku-suru is operated by Codama. If you have a question about this Privacy Policy, about how we handle Google user data, or about a request concerning your personal information, write to support@yoyaku-suru.com. We may update this Privacy Policy from time to time. When we do, we will change the date shown at the bottom of this page and, where the change is significant, tell account holders directly.