Sched.cloud Closed Beta Privacy Policy

Effective 26 September 2026.

This policy applies while Sched.cloud is in closed beta, together with the Closed Beta Terms of Use.

1. Who we are

The closed beta is organised and operated by Rebit Software Kft. (registered seat: 1112 Budapest, Virágkertész utca 4., building C, 2nd floor 6., Hungary; company registration number: 01-09-326911; tax number: 26374826-2-43). We are the controller for organising our own testing programme, participant accounts and operational security. Send questions, rights requests or consent withdrawal to support@rebitsoft.com or our registered seat. The beta does not cover processing business customers' data on their behalf; roles and data processing terms must be settled separately before that use.

This notice covers applicants, account holders, booking-page visitors, meeting attendees, people sent meeting options or polls, invitees and people named in access rules. Only people admitted in advance may have their data used in the restricted testing programme. We also explain technical processing for visitors to public pages who are not participants. If the Hungarian and English versions differ, the Hungarian text prevails without limiting mandatory data subject or consumer rights.

2. In short

• Sched.cloud finds meeting times across Google and Microsoft calendars and books the meeting in the organizer’s own calendar.
• For availability, we request busy intervals from Google. On Microsoft we request calendar entries' start, end, availability and cancellation status; technical identifiers added by the provider are ignored for the calculation. We do not request existing event titles, descriptions, locations or attendees for this purpose. We do process and store content you supply for meetings created through Sched.cloud.
• When you are busy is not stored. It is read when needed and discarded as soon as the answer has been worked out.
• Others see offered times according to your settings. For authorised participants, the planner also identifies who cannot make a particular time. We do not disclose raw busy intervals to them, but offered times and indications can allow inferences about your availability.
• Your data is stored in the European Union, in Microsoft Azure’s Poland Central region. Emails are delivered for us by Brevo, which we use for nothing else.
• We do not sell personal data, show advertising, use tracking, or build profiles of you. On the pages you see before signing in, we use analytics (Google Analytics) only if you accept it.

3. What we collect

If you have an account

• Account: email address, verification status, first and last name, time zone and salted password hash; not the password itself. We record the accepted terms version and acceptance time, and the inviter when an invitation link was used. Verification and password-reset links involve expiry and usage records and a digest of the token.
• Meeting defaults: if you add them, your own video link, an address for meeting in person and a phone number for guests to call. Each is written into the invitation of every meeting at that place, so everybody invited sees it, and is kept until you change it or close the account. You can give one for a single meeting, a quick meeting or a service on your booking page in place of these; one kept with a quick meeting or a service is kept until you change or delete it.
• Profile: if you add them, a short title, such as your role, a short introduction, up to six links to your pages elsewhere, and a picture. A picture is re-encoded to 400 × 400 pixels when you upload it, and everything else in the file — such as where and with what device it was taken — is dropped.
• Calendar connections: the provider (Google or Microsoft), the email address and identifier of the connected account, the permissions you granted, the connection’s status, and an encrypted refresh token that lets us act on your calendar. We also store the names of the calendars in that account and which of them you chose to use.
• When you are busy: read live from your calendar provider as the start and end of busy periods (on Microsoft, the start, end and status of each calendar entry, such as busy, tentative or out of office). It is held in memory only while an answer is computed, and never stored.
• Availability and booking page: your meeting hours, buffers, notice and other rules; your booking page handle, display name and bio; and your event types. Your booking page is public to anyone with its link, unless you limit it, or one of its event types, to people signed in to Sched.cloud.
• Access settings: who may book with you or see your availability, including any email addresses or domains you list in your rules, whether people can find you by the address of a connected calendar account, and the requests you send and receive to see someone’s availability.
• Meetings: for each meeting booked through Sched.cloud, its time, title, description, location, video-call link, calendar, status, and the provider’s identifier for the calendar event. The attendees’ addresses are sent to Google or Microsoft as part of the event; we do not keep them with the meeting.
• Address book: the people you met through Sched.cloud — whom you invited, who invited you, and who booked on your booking page — with how often and when you last met, so that the planner and your address book can offer them to you. Only you can see it. The people you exchanged requests with, in either direction, and your colleagues appear in it too, but are not stored there.
• Invitations you send: addresses you invite from the Invite page, so that you can see what you sent (see “If someone invites you to Sched.cloud” below).
• Meeting options you send: the times you offer, the addresses you send them to, and for each person whether and when they booked, so that you can follow and withdraw what you sent. Each person’s link is stored only as a digest.
• Polls you send: the times you offer, the addresses you send them to, and for each person the name they voted under, the times they chose and when they last voted, so that you can see the result and book a time. Each person’s link is stored only as a digest.
• Quick meetings: the meetings you save on the Events page to send in one press — their title, description, length and settings, and the email addresses you put in them — until you change or delete them. Only you can see them.
• Planner draft: the meeting you last put together in the planner and did not send — its title, description, length, place with its video link, address or phone number, and settings, and the email addresses you added — so that it is there when you come back. Only you can see it.
• Notifications: notices shown to you inside Sched.cloud, such as a new request or a booking on your page.

If you book a time on someone’s booking page

• You give us your name, email address and, if you wish, a note. We use them to book the meeting with the page’s owner, whose settings decide whether it is booked straight away, waits for their approval, or cannot be accepted.
• If the meeting is booked, it is created in the owner’s calendar with you as an attendee, and Google or Microsoft sends you the invitation. The event’s title contains your name. Your note is not put in the event: the owner reads it on Sched.cloud, where it is kept with the booking. We do not keep your email address with the booking.
• If the request waits for the owner’s approval, we keep your name and email address with the request, so that the owner can decide.
• Once the meeting is booked, the page’s owner keeps your email address in their address book until twelve months after your last meeting, so that they can find you again. Only they can see it.
• Your network (IP) address is used briefly, in memory only, to limit how many requests can be made. We do not store it.

If someone adds you to a meeting or looks up your address

• A Sched.cloud user can type your email address into the planner to arrange a meeting. We receive your address from that user.
• If you have no account, we record only a pseudonymised (hashed) form of the address, for that day, to limit how many addresses one person can check. If the user books the meeting, your address is sent to their calendar provider as an attendee, and kept in their address book (see section 8).
• If you have an account, the user is told whether they can schedule with you and, if your Access settings allow it, which times suit you (see section 6). Unless you change those settings, people on Sched.cloud can do this without asking you first; you can require a request, or refuse, on the Access page. Each such check and lookup is recorded, and you can see the lookups on your Access page.
• If you have an account: somebody who books a meeting with you is kept in your address book, and you in theirs; both sides of a request, however it ended, appear in each other’s address book, which never says how it ended; and somebody your Access settings let plan with you can see your profile — your name, and your booking page with the event types listed on it.

If someone sends you meeting options

• A Sched.cloud user can send you a few of their free times, so that you book one of them as a meeting with them. We receive your address from that user, and email you a link of your own, valid until the deadline they chose. The email names them and their confirmed address.
• We keep your address with what they sent, and whether and when you booked, so that they can follow it. Your link is stored only as a digest: nobody, the sender included, can read it from our records.
• If you book a time, the meeting is created in their calendar with you as an attendee, and Google or Microsoft sends you the invitation. If you have a Sched.cloud account, or open one with that address later, you choose signed in, and the times your own calendar is busy for are marked for you alone.
• If you have no account, the email carries the same opt-out link as an invitation to join (see below), and opting out stops these emails too. Your address and the record of what was sent are deleted 30 days after the meeting options close; a meeting you booked is kept like any other (see section 8). If the sender gave the meeting no title, it is named after the two of you, by first name, or, since we know no name for you, by your email address — so that address stays in the meeting’s title for as long as the meeting is kept.

If someone sends you a poll

• A Sched.cloud user can send you a few times to vote on, to find one time for a meeting with everybody they asked. We receive your address from that user, and email you a link of your own, valid until voting ends. The email names them and their confirmed address. Your link is stored only as a digest.
• When you vote, you choose any of the times, or none, under a name the others on the poll see beside your vote: your account’s name if you have a Sched.cloud account, otherwise the one you type. Everybody holding a link to the poll sees the names of those who voted and the times each chose, but not their email addresses. Once a time is booked, the calendar invitation lists everybody it invites, with their addresses, as any meeting’s does. The sender sees your address, your name and your choices. You can change your vote until voting ends.
• If you have a Sched.cloud account, or open one with that address later, you vote signed in, and the times your own calendar is busy for are marked for you alone. You can still vote for them.
• When a time is booked — by the sender, or automatically when voting ends if they chose that — the meeting is created in their calendar with everybody who can be invited, and Google or Microsoft sends you the invitation. If your Access settings ask the sender to request before booking you, your vote counts as agreeing to this one meeting, and if you did not vote you are left off it; if you no longer accept their requests by then, you are left off whatever you voted.
• If you have no account, the email carries the same opt-out link as an invitation to join (see below), and opting out stops these emails too. Your address, name and votes are deleted 30 days after the voting deadline, or after the poll is withdrawn; a meeting booked from it is kept like any other (see section 8).

If someone invites you to Sched.cloud

• A joining invitation is permitted on the basis of your prior, specific and demonstrable consent. We receive permission and the relevant name and address directly from you; if another tester forwards your declaration, that tester is the source, and the operator checks its authenticity and scope before sending. Saying 'I know the recipient' is not consent.
• The email names the person who invited you and their confirmed address, says why you received it, and contains a link to create an account. Nobody creates an account for you.
• The email delivery provider receives your address and the message to deliver the invitation. After a Sched.cloud invitation alongside a meeting, the application records an address digest, the inviter and sending circumstances. An invitation initiated on the Invite page also stores the address; other associated record data may remain after that address is cleared. Section 8 explains retention.
• After opening the opt-out link you must confirm suppression. This prevents further Sched.cloud joining invitations from any user; we keep an address digest on a suppression list to honour it. You can also withdraw consent by email or post. This does not automatically delete your account, cancel existing meetings or stop calendar invitations sent by Google or Microsoft.

Prior beta consent: we keep a separate record of each declaration: the declarant's name and email address, the exact wording and its version, the version of this policy they were given, when and how the declaration was made, the result of our check, and any withdrawal. The record is not public and not a shared address book. We check it before an invitation is sent; the application does not check it by itself.

For security and to run the service, about everyone

• Audit records: a record of security- and privacy-relevant actions, such as sign-ins, connecting or disconnecting a calendar, every lookup of someone’s availability (who, whose, which period, and the result), access requests and decisions, bookings and cancellations, invitations, changes to settings, and every action of our staff. Audit records never contain calendar contents, passwords or tokens.
• Technical logs: one line per request, with an identifier, the page or function called, the result and how long it took. Email addresses, passwords, tokens and cookies are removed before a line is written. The application does not log IP addresses or the contents of requests.

4. Why we use it, and on what legal basis

Invitation consent is voluntary: without it no invitation may be sent, but it is not a general condition for using an existing account. Withdrawal does not affect earlier lawful processing. Messages for account verification, requested password reset and necessary service operation relate to performing the contract and are not used for advertising. A test meeting's calendar invitation is a separate operation sent by Google or Microsoft. A booking requires the necessary name and address; registration requires a first and last name, an email address and a password. A bio and note are optional. You may object to processing based on legitimate interests.

5. Your Google or Microsoft calendar

To connect a calendar, you sign in at Google or Microsoft and approve the permissions we ask for there. We use them only to read when you are busy, to list your calendars so that you can choose which ones to use, and to create, change and cancel the meetings you book through Sched.cloud, with a Google Meet or Microsoft Teams link if you ask for one, and to check whether those meetings are still on, so that one you cancel in your calendar is shown as cancelled here.

The permissions can technically allow broader access than Sched.cloud uses. The application enforces data minimisation for availability calculations. The Google calendar list can include shared calendars; the calendar.events.owned permission used for event management is limited to owned calendars. Connecting a calendar is not general marketing consent.

Sched.cloud’s use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. We do not use Google or Microsoft calendar data for advertising, do not sell it, do not transfer it to anyone except as needed to provide the features described here or as required by law, and do not let people read it.

Disconnecting deletes the locally stored refresh token and the connection's calendar list. We also attempt provider-side revocation for Google; Sched.cloud does not perform such revocation for Microsoft. Revoke the provider authorisation fully in your Google or Microsoft account settings or through your administrator. Created events may remain in other people's calendars; Sched.cloud no longer manages them after disconnection.

6. What other people can see

• Your booking page (display name, bio, event types) is public to anyone with its link, unless you limit the page, or an event type, to people signed in to Sched.cloud. Visitors see only the times they can book, never when you are busy or why a time is unavailable. Booking pages ask search engines not to index them.
• Your profile (title, introduction, links and picture) is shown on your booking page, to whoever can open the page; in search results, your picture and title only, to people signed in; and on your profile card, to people your Access settings let plan with you. Your picture has an address nobody can guess, but anyone who has that address, for example from your public booking page, can open it.
• Search. People signed in to Sched.cloud can find you by your name, and the results show your picture and title if you added them. Search never shows your address, and being found gives nobody more than your Access settings do. It is on unless you switch it off on the Access page; your booking page is in search only if you put it there.
• People who add you in the planner. A signed-in user who types your address is told whether you are on Sched.cloud and whether they can schedule with you, need to ask you, are waiting for your answer, or cannot ask. One person can check at most 200 addresses a day, and each check of a registered person is recorded. Pages that need no sign-in, such as the booking page, sign-up and password reset, never reveal whether an address has an account.
• Who can make a time. If your Access settings let people on Sched.cloud plan with you without asking (the default), you allowed someone’s request, someone allowed yours, or you share an organization in Sched.cloud, the planner shows them for each time how many people can make it and names those who cannot. It never shows your busy periods.
• Access requests. When someone asks to see your availability, you see their primary address. They see only whether the request is waiting or cannot be made, never why. Allowing a request works both ways: by asking, they agree that you can see their availability and plan with them too. Either of you can take this back on the Access page.
• Who has looked. On your Access page you can see each time someone looked up your availability and what they got.
• Finding you. Off unless you turn it on. When on, people can find you in the planner by the address of a connected calendar account, not only by your Sched.cloud address.
• Suggestions and the address book. The planner suggests people, and the address book lists them, only to someone who already has a relationship with them: a person they met through Sched.cloud in the last twelve months, a person in the same organization, or a person on the other side of a request, however it ended. Anybody else is found only by their whole email address, within the planner’s daily limit, and the check is recorded for them to see.
• Meeting attendees receive the calendar event from the organizer’s calendar. It carries the organizer’s instructions, a booking-page visitor’s name in its title, where the meeting is — the organizer’s address, video link or phone number, if they chose that place — and a short line saying that the meeting was booked with Sched.cloud. A visitor’s note is not in it.

7. Who else receives personal data

• Microsoft Azure runs Sched.cloud. The application, its database, its logs and the key that protects calendar tokens are in the European Union, in the Poland Central region.
• Brevo (Sendinblue SAS, France) is used only to deliver the emails Sched.cloud sends, and for nothing else. These are system messages (confirming an email address, resetting a password, notices about your account), the invitations users send, and the meeting options and polls users send. For that, Brevo receives the recipient’s address and the message, and it delivers from the European Union. The emails carry no tracking of opens or clicks.
• Cloudflare (Cloudflare, Inc.) checks that a person, not an automated program, sends the sign-in, registration, password-reset and booking-page forms. For that, the check runs in your browser from Cloudflare’s servers, and Cloudflare receives your IP address and technical details of your browser and connection. Sched.cloud learns only whether the check passed. Cloudflare uses this data to detect automated programs and to improve that detection, not to identify or profile you. Cloudflare, Inc. is based in the United States, so this data may be processed outside the European Union.
• Google (Google Ireland Limited, Ireland; Google LLC, United States) provides Google Analytics, which measures visits to the pages you see before signing in. It loads and sends data only if you accept analytics, in the cookie notice or on the Cookie Policy page. Google receives your IP address, which Google Analytics shortens, and details of the pages and your browser. Google may process this data outside the European Union. Advertising features and Google Signals are switched off.
• Google and Microsoft provide your calendar under your own agreement with them. They are not our processors. We exchange data with them only on your instruction: when you connect a calendar, when availability is looked up as your settings allow, and when a meeting is booked or cancelled.
• Our staff can see account details, the status of calendar connections, and meeting details when needed to run the service or answer a request. Any view that names a person requires a recorded reason and is logged. Staff cannot see calendar contents or tokens, and cannot sign in as you.

We do not use advertising or tracking services. From other companies the site loads Cloudflare’s check on the forms named above and, only if you accept analytics, Google Analytics on the pages you see before signing in.

8. How long we keep it

Deleted data can remain in database backups for up to 35 days before the backups themselves are overwritten.

9. How we protect it

• Every connection is encrypted (TLS), and browsers are told to use only secure connections.
• Calendar refresh tokens are encrypted (AES-256-GCM), and the key is kept apart from the database. Short-lived access tokens are never written to disk.
• Passwords are stored only as a salted hash. Confirmation, reset and invitation links expire and work only once.
• Each person’s data is separated in the database itself, not only by the application. The database cannot be reached from the internet.
• Limits on requests, sign-in attempts, address checks and invitations make misuse harder.
• Every lookup of another person’s availability and every staff action is recorded. The application cannot change those records, and they are deleted only once the period in section 8 has passed.
• Our staff administration site is separate from Sched.cloud, and staff sign in to it with a password and a code from an authenticator app.

10. Automated decisions

When someone asks to book time with you, the rules you set decide automatically whether the meeting is booked, waits for your approval, or is declined. We do not score or profile anyone, and no decision is made about you that has legal or similarly significant effects.

11. Your rights

You may request access and a copy, correction, and erasure or restriction subject to GDPR conditions. For automated processing based on consent or contract, you may request portability of data you provided. You may object on grounds relating to your situation to legitimate-interest processing; after an objection to direct marketing we stop processing for that purpose. You may withdraw consent free of charge. Send requests to support@rebitsoft.com. We inform you of action without undue delay and within one month; where justified, this may be extended by two further months, with reasons notified within the first month. Handling is normally free; we request only necessary information to verify identity.

• You can disconnect a calendar yourself at any time, which ends our access to it.
• If you received an invitation and have no account, the link at the bottom of the email stops all future invitations.
• If you think we have handled your data unlawfully, you may complain to the Hungarian National Authority for Data Protection and Freedom of Information (NAIH, 1055 Budapest, Falk Miksa utca 9–11, naih.hu) or to the supervisory authority where you live or work, and you may also go to court.

12. Children

The closed beta admits people aged 18 or over. Do not enter children's data in the test. If such data nevertheless reaches us, we assess the lawfulness and necessity of processing and erase it where appropriate.

13. Cookies

Alongside cookies necessary for sessions and calendar-connection security, a cookie can remember that you closed the cookie notice, for a year, and only if you choose that on the notice. See the Cookie Policy.

14. Changes

We provide clear information before a new processing purpose or material change. Amending this notice does not create consent or expand earlier permission. Account holders receive necessary updates by email; unregistered participants receive the relevant information before giving consent and at first contact.