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.
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.
- 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
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.
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.