Security and data handling

What Meetris does with a calendar

Meetris finds a meeting time that works for a group. An organizer signs in with Google or Microsoft, creates a request and shares a link. Each invitee either connects their own calendar, so Meetris can read when they are busy, or types their free times in by hand. Meetris computes the times everyone is free, a time is chosen, and Meetris writes one event to the organizer’s calendar with the invitees as guests. That event is the only thing scheduling ever writes.

One separate feature, Clear My Day, reads the events on a person’s own calendar so it can show them their day and move their meetings. It runs only when they open it, it reads only their own calendars, and it is described on its own below.

Permissions requested

Two consent screens exist, and they ask for different things. Organizers, who have events written on their behalf, are asked for write access. Invitees, who only share when they are busy, are not.

The contacts permissions are never part of sign-in. They are requested from one button, for the account the calendar is already connected to, and a consent that comes back from a different account, or without the contacts permission in it, stores nothing. The feature is switched off for all accounts until Google’s review of its two permissions completes; the Microsoft permission needs no review, and waits on the same switch.

If a person clears a calendar box on Google’s consent screen, the sign-in is refused before anything is stored: no account, no token, no session. They are asked to sign in again and allow calendar access.

Why each permission is needed

• calendar.events and Calendars.ReadWrite: to create the confirmed event, update it on a reschedule, cancel it, and read it back to see whether guests accepted. Asked of organizers only, because every calendar write goes through the organizer’s own account; an invitee’s grant is never used to write anything. Neither provider offers a permission that writes an event without also being able to read events, so on paper this is also read access. What is actually read with it is listed in the next section.
• calendar.freebusy and Calendars.Read: the read scheduling runs on. Which intervals are busy, and nothing about what is in them.
• calendar.calendarlist.readonly: to list a person’s calendars, so they can choose which ones count towards their availability and where events are written, and so Meetris can tell a calendar they own from one shared to them.
• contacts.other.readonly and contacts.readonly (Google, on request): to search the names and email addresses of the people the organizer has emailed and the contacts they have saved, for what they type when inviting someone, so they can pick an invitee by name. Names and addresses are the only fields read; no phone numbers, photos or notes. Nothing is stored, and nothing is written to the address book.
• People.Read (Microsoft, on request): the same search through Microsoft Graph’s people list, which ranks the organizer’s saved contacts and the people they have corresponded with, and on a work account can include colleagues from the directory they have interacted with. Display name and email addresses are the only fields read. Nothing is stored, and nothing is written to the address book or the directory.
• MailboxSettings.Read (Microsoft only): the mailbox time zone, which Microsoft does not attach to calendars. Best effort: a grant without it falls back to UTC.
• offline_access and the refresh token it produces: so availability can be re-read at booking time without asking the person to sign in again.
• openid, email, profile and User.Read: name and address, to create the account.

What is read, and from whose calendar

An organizer never sees an invitee’s event titles, guests or contents. There is no path in the product that shows one person the contents of another person’s calendar.

Clear My Day is the only feature that reads event contents, and it reads them from the user’s own calendar. The titles it reads are shown back to that user, stored with the plan for that day, and included in the email sent to a meeting’s organizer when the user asks them to move it. It works on Google and Microsoft accounts.

What is written to calendars

• One event per confirmed meeting, on the calendar the organizer chose, with the invitees as guests. Guests receive the ordinary Google or Outlook invitation. The event is updated when the meeting is rescheduled and deleted when it is cancelled.
• Meetris reads that event back, on the organizer’s calendar, to learn whether guests accepted or declined. It does this on a schedule and, where the provider supports it, on a push notification from the provider when the event changes.
• Invitees’ calendars are never written to. The event reaches them as guests of the organizer’s event.
• A person can give an organizer standing permission to read when they are busy, so they are not asked for each meeting. It reads free/busy only, from the calendars the person picked, and they can withdraw it from their People page at any time. Whether the organizer picks the time by hand or lets Meetris book the best one unattended is the organizer’s setting; the event lands the same way either way.
• Clear My Day, when a person presses the button, moves the meetings they organize on their own calendar to another time (the provider notifies the guests) and sends a request to the organizers of meetings they do not own. It acts only on calendars they picked and can write to, and never runs unattended.

Allowlisting Meetris

These are the identifiers an admin needs. They are the same values every browser is sent to on sign-in; the secrets that go with them are not on this page or anywhere public.

Google Workspace: in the Admin console, under Security, Access and data control, API controls, Manage third-party app access, add the client ID above and mark it Trusted. Meetris requests only Calendar scopes, which Google classes as sensitive rather than restricted, and Google completed its verification of the app on 26 August 2026.

Microsoft 365: the app is registered for any organization. If your tenant requires admin consent, the link above grants it for everyone in the tenant in one step. After consenting you are returned to meetris.ai, where the page reports that a sign-in did not complete; that is expected, since no sign-in was in progress, and the consent has been recorded in your tenant.

Microsoft has not yet completed its review of Meetris as a publisher, so its consent screen carries an “unverified publisher” notice. Meetris tells people this before sending them to that screen. Tenants that block consent to unverified publishers can still allow the app through the admin consent link above.

Where data is processed

Google and Microsoft are the calendar providers a person connects, and are not listed because they hold the calendar in the first place. No calendar data is sent to any AI provider: the assistant reads only the email a person copied it on, and its prompt has no calendar field.

What is stored, and for how long

Security measures

• All traffic between browsers, Meetris and the calendar providers is over HTTPS.
• Provider refresh tokens are encrypted at rest. The keys are held in the application’s configuration, not the database, and can be rotated without anyone reconnecting a calendar.
• Sign-in sessions are recorded server-side and checked on every request. The cookie is HttpOnly, Secure and SameSite, and carries a signed reference rather than any account data. Sessions end after 7 days without use and 30 days regardless.
• The API applies per-IP rate limits.
• Inbound webhooks are authenticated: email delivery notifications by signature, and calendar push notifications by matching the channel token Meetris issued when it registered the channel.
• Error reports leaving the browser have OAuth tokens and authorization headers stripped first, and page-view measurement reports the route pattern rather than the URL, so an invitation link is never sent to either.

When someone leaves the company

Disable their Google or Microsoft account, or revoke Meetris’s access from your admin console or their third-party access page. Meetris’s refresh token stops working on its next use, the connection is marked as needing reconnection, and nothing further is read or written on their behalf: no availability is shared under a standing permission, no meeting is booked, no event is touched. An invitee whose calendar cannot be re-read is treated as unverified, and a meeting is not booked on their cached data, by the organizer or unattended.

Their Meetris account, its meetings and its permissions remain as records until the account is deleted. The person can delete it from Settings. If they no longer can, write to privacy@meetris.ai; we verify the request and run the erasure.

Deleting an account

• Meetings the person organized are deleted, along with the busy intervals and permissions attached to them. Invitees a request was still waiting on get one email saying it was withdrawn, and our copy of that email stops naming the organizer once it is sent. Where the person appears as an invitee in someone else’s meeting, their name and address are anonymised, any availability they shared is deleted, and they are taken off meetings that have not yet happened.
• Stored refresh tokens are deleted. Meetris does not call the provider to revoke its own grant, so the app stays listed under the account’s third-party access until it is revoked there. Nothing can use that grant once the token is gone, but revoking it keeps the list accurate.
• Events already on calendars stay where they are. Meetris does not delete calendar events on account deletion.
• Emails the person sent to the assistant, the records of email Meetris sent to them, and the records of invitations sent for their meetings are deleted with the account.
• A self-service deletion keeps the address on the beta access list, so the person could sign in again. An erasure requested through privacy@meetris.ai removes that too.

Reporting a security issue

Write to privacy@meetris.ai. Include what you found and how to reproduce it. We reply to every report, and we do not take action against good-faith research.

What this page does not claim

Meetris holds no SOC 2 report or ISO 27001 certification, and has not commissioned an external penetration test. It offers no single sign-on beyond Google and Microsoft sign-in, no SCIM provisioning, and no company-level view of which employees use it. If any of those is a condition, the answer today is no, and this page will say so until it changes.