We use broad language in our privacy policy regarding how we utilize third party services.

For primary integrations (e.g. calendar, email, task management integrations), we take special care with how we handle that data.

All of our integrations follow roughly the same principles, with any exceptions detailed below:

Only request data that's needed to provide user-facing features: We limit the usage of our data to specifically what you see and use in the app. We request the minimum authorization scopes needed to retrieve this data.

Limit data that's stored on our servers to the bare minimum: We don't store any information about the contents of your 3rd party data on our servers or databases or share this data with any of the analytics tools that we use. We store only the tokens needed to request data that's initiated by your in-app actions. The data that's shown in the app is only being stored in the client's browser cache, and isn't accessible outside of your session.

Do not share 3rd party data with people who don't already have access to it: If you use Sunsama as part of a shared workspace with other users, your 3rd party data will not be visible to other people in your workspace unless they already have access via the 3rd party service. For example, your calendar events won't be visible to other people in your workspace unless you've already shared your calendar with them via Google Calendar. The only exception is that if you create tasks in Sunsama via importing from a 3rd party integration, the title of those tasks will be visible to other users in your workspace.

Google Calendar integration

Authentication and scopes

We use Google Calendar's OAuth 2.0 flow for authenticating and authorizing all calendar requests.

We request the minimum scopes required to:

• View and edit calendar events across all of the calendars you have access to

calendar.events

calendar.readonly

Data storage

We store the following calendar related data:

• Authorization tokens needed to make API requests
• The list of calendars you have access to, and basic details about each calendar, so that you can choose which calendars you want to view within Sunsama

We do not store copies of your calendar events in our database. All of the calendar event data is fetched by the client, and stored only in the client cache. Calendar event data is not stored in a Sunsama database. The only exception is if you import calendar events (in that case we copy the title, location, invitees, and description) or add data to calendar events that can't be stored in Google Calendar (for example, meeting notes). In this case, we'll store a copy of the event details in our database to preserve the custom Sunsama content linked to it.

Gmail integration

Authentication and scopes

We use Gmail's OAuth 2.0 flow for authenticating and authorizing all email requests.

We request the minimum scopes required to:

• Browse your emails
• Modify an email's status (archive/mark as read/delete/star/label):

gmail.modify

Data storage

We store the following email related data:

• Authorization tokens needed to make API requests

We do not store copies of your emails in our database. All of the email event data is fetched by the client, and stored only in the client cache. Email data is not stored in a Sunsama database.

Third Party Security Assessment

In order to provide an integration with Gmail, we remain in compliance with Google's OAuth Verification Standard. Our app and infrastructure have been reviewed by an independent security assessor. This assessment helps keep Google users’ data safe by verifying that Sunsama demonstrates a minimum level of capability in handling data securely and deleting user data upon user request. If you'd like a copy of our third party security assessment, you can reach out to us at [email protected].

Outlook Calendar integration

We use Microsoft's OAuth 2.0 flow for authenticating and authorizing all calendar requests.

We request the minimum scopes required to:

• View and edit calendar events across all of the calendars you have access to

Calendars.ReadWrite

Data storage

We store the following calendar related data:

• Authorization tokens needed to make API requests
• The list of calendars you have access to, and basic details about each calendar, so that you can choose which calendars you want to view within Sunsama

We do not store copies of your calendar events in our database. All of the calendar event data is fetched by the client, and stored only in the client cache. Calendar event data is not stored in a Sunsama database. The only exception is if you import calendar events (in that case we copy the title, location, invitees, and description) or add data to calendar events that can't be stored in Outlook Calendar (for example, meeting notes). In this case, we'll store a copy of the event details in our database to preserve the custom Sunsama content linked to it.

Outlook Email integration

Authentication and scopes

We use Microsoft's OAuth 2.0 flow for authenticating and authorizing all email requests.

We request the minimum scopes required to:

• Get basic user information (profile pictures/name/etc)
• Browse your emails
• Move an email (archive/delete/etc)
• Modify an email's status (mark as read/flag/label/etc)

[User.Read, Mail.ReadWrite]

Data storage

We store the following email related data:

• Authorization tokens needed to make API requests
• Unique email identifiers (id, internetMessageId, conversationId) to allow fetching specific emails

We do not store copies of your emails in our database. All of the email data is fetched by the client, and stored only in the client cache. Email data is not stored in a Sunsama database. The only exception to this rule is that the email subject line is copied to our task title when creating an email task.

GitHub integration

Authentication and scopes

We use GitHub's OAuth flow for authenticating and authorizing all GitHub requests.

We request the minimum scopes* required to:

• Browse your issues and PRs across all your repos/projects
• Modify an issue/PR's status (close/open/merge)

repo

read:org

❗️

GitHub Scopes

Unfortunately, in order to simply view all of your Github Issues, the only scope that Github provides is the repo scope. Regrettably, this scope is quite broad and also grants an application access to a variety of other data (that we don't actually use).

We're hopeful that one day Github will release more granular scopes that will allow us to access to what we need without also gaining access to sensitive items, like those that you mentioned.

Data storage

We store the following GitHub related data:

• Authorization tokens needed to make API requests

We do not store any of your issues/PRs in our database. All of the issue/PR data is fetched by the client, and stored only in the client cache. Issue/PR data is not stored in a Sunsama database.

Jira integration

Authentication and scopes

We use Jira's OAuth flow for authenticating and authorizing all Jira requests.

We request the minimum scopes required to:

• Browse your issues across all your projects/boards
• Modify an issue's status

read:jira-work

read:jira-user

write:jira-work

offline_access

Data storage

We store the following Jira related data:

• Authorization tokens needed to make API requests

We do not store copies of your issues or projects in our database. All of the Jira data is fetched by the client, and stored only in the client cache. Issue/project data is not stored in a Sunsama database.

Linear integration

Authentication and scopes

We use Linear's OAuth flow for authenticating and authorizing all Linear requests.

We request the minimum scopes required to:

• Browse your issues
• Modify an issue's status

read

write

Data storage

We store the following Linear related data:

• Authorization tokens needed to make API requests

We do not store copies of your issues or projects in our database. All of the Linear data is fetched by the client, and stored only in the client cache. Issue/project data is not stored in a Sunsama database.

Monday integration

Authentication and scopes

We use Monday.com's "Personal Access Tokens" for authenticating and authorizing all requests to the Monday API.

This token allows Sunsama's integration the same permissions to your Monday workspace as your user account. In other words, it can only see/edit what you can see/edit when logged in and doesn't have access to things in the workspace you could not edit yourself.

Data storage

We store the following Monday related data:

• Personal access token needed to make API requests

We do not store copies of your tasks or projects in our database. All of the Monday data is fetched by the client, and stored only in the client cache.

Trello integration

Authentication and scopes

We use Trello's OAuth 2.0 flow. Trello does not support granular authentication permissions, as such, there are no scopes associated with the Trello integration. Sunsama's permissions are connected at the Trello account level, which grants permissions to data in all Trello workspaces your Trello account is a member of.

Data storage

We store the following Trello related data:

• Authorization tokens needed to make API requests

We do not store copies of your tasks or projects/folders/lists in our database. All of the Trello data is fetched by the client, and stored only in the client cache. Task/project data is not stored in a Sunsama database.

Todoist integration

Authentication and scopes

We use Todoist's OAuth 2.0 flow. Todoist does not support granular authentication permissions, as such, there are no scopes associated with the Todoist integration. Sunsama's permissions are connected at the Todoist account level, which grants permissions to all data your Todoist account has access to see.

Data storage

We store the following Todoist related data:

• Authorization tokens needed to make API requests

We do not store copies of your tasks or projects/filters/labels in our database. All of the Todoist data is fetched by the client, and stored only in the client cache. Task/project/label/etc data is not stored in a Sunsama database.

ClickUp integration

Authentication and scopes

We use ClickUp's OAuth 2.0 flow. ClickUp does not support granular authentication permissions, as such, there are no scopes associated with the ClickUp integration.

Data storage

We store the following ClickUp related data:

• Authorization tokens needed to make API requests

We do not store copies of your tasks or projects/folders/lists in our database. All of the ClickUp data is fetched by the client, and stored only in the client cache. Task/project data is not stored in a Sunsama database.

Asana

Authentication and scopes

We use Asana's OAuth flow. Asana does not support granular authentication permissions, as such, there are no scopes associated with the Asana integration.

Data storage

We store the following Asana related data:

• Authorization tokens needed to make API requests

We do not store copies of your tasks or projects in our database. All of the Asana data is fetched by the client, and stored only in the client cache. Task/project data is not stored in a Sunsama database.

Slack integration

Authentication and scopes

We use Slack's OAuth 2.0 flow for authenticating and authorizing all Slack requests.

We request the minimum scopes* required to:

• Post messages to the Slack channel of your choosing from Sunsama
• Create Sunsama tasks via Slack message actions
• Create Sunsama tasks via Slack commands
• @mention teammates via Sunsama comments
• Unfurl Sunsama urls

app_mentions:read

channels:join

channels:manage

channels:read

chat:write

commands

groups:read

im:history

im:read

im:write

links:read

links:write

mpim:history

mpim:read

mpim:write

team:read

users:read

users:read.email

users:write

*Slack has highly granular scopes, which is why there are so many needed to support the minimum functionality

Data storage

We store the following email related data:

• Authorization tokens needed to make API requests

We do not store copies of your Slack messages, channels, or users in our database. All of the Slack data is fetched by the client, and stored only in the client cache.

AI Customizations

Your data is not used to train models and it's encrypted

We use Google's Vertex AI to back our AI Customizations because it provides high quality privacy:

• Data is encrypted in transit
• Your data is not used to train Google's models

Learn more from Google's docs directly.

Always Opt In

Sunsama's AI features are an opt-in feature. No customer data is used for embedding until the feature is explicitly enabled by the user.