Skip to content
Security

Your users trust you with their calendars

Pyas sits between your app and your users' Google, Outlook and Zoom accounts. Here is what it keeps, what it never keeps, and how it protects the rest.

Data

What Pyas stores

Events stay in Google Calendar and Outlook. Pyas reads them when your app asks and keeps only what it needs to connect accounts and report changes.

Connected account
Name, email, provider, the scopes the user granted, and the access and refresh tokens, encrypted.
Change tracking
For each watched event: its IDs, its start time and a fingerprint (a hash), so a change is reported once. No titles, descriptions or attendees.
Webhook deliveries
The exact body sent, kept 30 days so you can replay it. Event and calendar changes carry IDs only.
Request log
Route, status, IDs and error codes for each request, without bodies, kept 7 to 30 days by plan.
Your metadata
Anything your app saves on an event or calendar, until you delete it or the account.
What Pyas never keeps
  • Event titles, descriptions or attendees in its change tracking
  • Attachments: they are read from the provider on each request
  • Your users' inboxes, contacts or files
  • Payment card numbers: Stripe handles payment
Controls

How the rest is protected

The same protections apply on every plan, the free one included.

Encrypted secrets
Provider tokens, Native Auth client secrets and webhook signing secrets are encrypted before they are stored.
TLS everywhere
HTTPS with HSTS on the API and dashboard. Live webhook endpoints must be HTTPS, and deliveries refuse private and internal addresses.
Test and live apart
A pyas_sk_test_ key reaches only the sandbox. A live key never sees it. Nothing you try in test touches a real calendar.
Scoped keys
Give a key read or write access, and an expiry of 30, 60, 90 or 365 days. Rotate with a grace period, and get a webhook before a key expires.
Signed webhooks
HMAC-SHA256 over the timestamp and body, checked against a 5-minute window. Rotate a signing secret and both signatures are sent while you switch.
Least access
Pyas asks providers for calendar and meeting access, plus each user's name and email, and Google user data is handled under Google's Limited Use requirements.
Sign-in

Reviewed by Google, Microsoft and Zoom

Users connect through Pyas Auth, which Google, Microsoft and Zoom have already verified. Each user sees exactly what Pyas will be able to do on their provider's own consent screen, and can take that access back from their account settings at any time.

Pyas's use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements.

Questions

Does Pyas store my users' calendar events?
Not to sync them. To report changes, Pyas keeps each watched event's IDs, its start time and a fingerprint (a hash), never its title, description or attendees. Reads may be cached for a few minutes so repeated requests don't hit Google or Microsoft again. Calendars hosted by Pyas itself are the exception: there, Pyas is the calendar, so it stores their events.
How are OAuth tokens protected?
Access and refresh tokens for Google, Microsoft and Zoom are encrypted before they are stored, as are Native Auth client secrets and webhook signing secrets. Requests to Pyas and to the providers go over TLS.
What happens when a user disconnects?
When your app deletes a connected account, Pyas stops its provider subscriptions, deletes its stored tokens and the metadata you saved on its events, and sends a connection.deleted webhook. A user can also revoke access in their Google, Microsoft or Zoom account settings at any time; Pyas then marks the account inactive and sends a webhook.
Can a test key reach real calendars?
No. A test key reaches only your app's sandbox, and a live key never sees the sandbox. The two are kept apart on every request.
How do I report a security issue?
Email support@pyas.io with what you found and how to reproduce it. Please do not test against other customers' data or Pyas's infrastructure without written permission first.