Workspace API user data and developer policy

As a developer using Google Workspace APIs, you often collect and manage sensitive user data. Please keep these key principles in mind:

  • Protect privacy: Don't use Workspace user data for prohibited uses. We prohibit third parties from selling user data or using user data for advertising purposes.
  • Be transparent: Accurately represent and explain to users what data you will collect, why you will collect it, and how you will use it.
  • Be respectful: Honor user requests to delete their data.
  • Be secure: Handle all user data securely and demonstrate you adhere to certain security practices.
  • Be specific: Don't request access to data that you don't need. All data access should only be to provide the user benefitting features of your application or service.

Workspace API Services User Data Policy

The Google API Services User Data Policy governs the use of all Google API Services when you, the developer, request to access user data. This Workspace API Services User Data and Developer Policy contains additional information that governs your use and access to Workspace APIs; including Gmail, Chat, Drive, Sheets, and other Google Workspace products, when you request to access user data.

In addition to the below policy, the Google APIs Terms of Service, Google Chat Acceptable Use Policy, Google Chat Developer Guide, Google Drive API Terms of Service, Google Drive Program Policies, Google Drive Developer Guide, Gmail Program Policies, Gmail Developer Guide, Google Apps Script Terms of Service and OAuth 2.0 Policies also govern your use of and access to the Workspace APIs and associated user data. Your use may also be governed by the Google Workspace Marketplace Developer Agreement. We also require that you comply with all applicable laws and regulations.

Please check back from time to time as these policies are occasionally updated. It is your responsibility to monitor and ensure your compliance with these policies on a regular basis. If, at any time, you cannot meet the requirements of our policies (or if there is a significant risk that you will not be able to meet them), please immediately stop using our services and reach out to us. We reserve the right to remove or restrict access to Google user data if you do not comply with this policy.

Appropriate access to and use of Google Gmail APIs

Requests to access user data must be clear and understandable. Google Workspace APIs may only be used in accordance with the applicable policies, terms and conditions, and for approved use cases as set forth in this Policy. This means you may only request access to permissions when your application or service meets one of the approved use cases. Only request access to Workspace APIs when your application or service meets one of our approved use cases.

Approved use cases for access to Gmail API scopes permissions are:

  1. Built-in and web email clients that allow users to compose, send, read, and process email via a user interface.
  2. Applications that automatically backup email
  3. Applications that enhance the email experience for productivity purposes (such as applications for customer relationship management, delayed sending of email or mail merge, or providing generative AI summaries)
  4. Applications that use information from emails to provide reporting or monitoring services for the benefit of users that improve the email experience (such as applications that automate travel itineraries or track flights or package delivery statuses)

The following application types are examples of apps that are not approved to access Gmail API scopes. These include, but are not limited to:

  1. Mobile keyboards.
  2. Applications that export email on a one-time or manual basis.
  3. Applications that store or backup data other than email messages in Gmail.
  4. Applications that use multiple accounts to abuse Google policies, bypass Gmail account limitations, circumvent filters and spam, or otherwise subvert restrictions.
  5. Applications that distribute spam or unsolicited commercial mail. For example, applications that send bulk commercial mail, such as customer relationship management, are approved as long as the user consented to receive emails.

Appropriate access to and use of Google Drive APIs

Only request access to Google Drive APIs when your application or service meets one of our approved use cases.

Approved use cases for access to Google Drive API scopes permissions are:

  1. Built-in and web apps that provide local sync or automatic backup of users' Drive files.
  2. Productivity and educational applications (for example, a task management, note taking, workgroup communications, and classroom collaboration applications) that only use Restricted Scopes to handle Drive files (or their metadata or permissions) via the application's user interface.
  3. Reporting and security applications that provide user or customer insight into how files are shared or accessed.

The Google Drive API is not allowed for certain use cases, including the following:

  1. Backup of user or app content from a developer's app or project to Drive.
  2. Cryptocurrency mining.
  3. Broad video distribution or dissemination of copyrighted content without authorization.
  4. Using Drive as a replacement for a large-scale content delivery network (CDN).
  5. File cloning tools that enable sharding of user storage and/or circumvention of Drive storage limits.
  6. Applications that use multiple accounts to abuse Google policies, bypass Google Drive account limitations, or otherwise subvert restrictions.
  7. Applications that distribute spam or unsolicited commercial messages. For example, applications that send bulk commercial messages, such as customer relationship management, are approved as long as the user consented to receive messages.

Appropriate access to and use of Google Chat APIs

Only request access to Google Chat APIs when your application or service meets one of our approved use cases.

Approved use cases for access to Google Chat API scopes permissions are:

  1. Built-in and web apps that allow users to compose, send, read, and process Chat messages or similar communication via a user interface.
  2. Applications that enhance the Chat experience for productivity purposes (for example, a task management Google Chat app that allows you to assign tasks to other members in the space).
  3. Applications that use information from Chat messages to provide reporting or monitoring services for the benefit of users (for example, an app notifying users a colleague is out of office).
  4. Applications that import messages, memberships, groups, or other similar Google Chat functionality.
  5. Applications that exchange and make use of data obtained via Google Chat APIs to interoperate with other messaging products, services, or features.

The Google Chat API is not allowed for certain use cases, including the following:

  1. Using Chat as a replacement for a large-scale content delivery network (CDN).
  2. Applications that use multiple accounts to abuse Google policies, bypass Google Chat account limitations, or otherwise subvert restrictions.
  3. Applications that distribute spam or unsolicited commercial messages. For example, applications that send bulk commercial messages, such as customer relationship management, are approved as long as the user consented to receive messages.

Request the minimum relevant permissions

You may only request access to permissions that are critical to implementing your application or service's functionality. This means:

Don't request access to information that you don't need. Only request access to the permissions necessary to implement your application's features or services. If your application does not require access to specific permissions, then you must not request access to these permissions. Don't attempt to "future proof" your access to user data by requesting access to information that might benefit services or features that have not yet been implemented.

Request permissions in context where possible. Only request access to user data in context (via incremental auth) whenever you can, so that users understand why you need the data.

Transparent and accurate notice and control

You need to have a privacy policy that discloses how your application or web service collects, uses, and shares user data.

Applications and services must also request access to user data in context (via incremental auth) you need the data, and how the data will be used. In addition to the requirements under applicable law, you must also adhere to the following requirements, which reflect our OAuth 2.0 and Google API Services User Data policies:

  1. You must provide a disclosure of your data access, collection, use, and sharing. The disclosure:

    1. Must accurately represent the identity of the application or service that seeks access to user data;
    2. Must be within the application itself if application-based or in a separate dialog window if web-based;
    3. Must be displayed in the normal usage of the application if application-based or website if web-based and not require the user to navigate into a menu or settings;
    4. Must provide clear and accurate information explaining the types of data being accessed, requested, and/or collected;
    5. Must explain how the data will be used and/or shared: if you request data for one reason, but the data will also be utilized for a secondary purpose, you must notify users of both use cases;
    6. Cannot be placed only in a privacy policy or terms of service; and,
    7. Cannot be included with other disclosures unrelated to personal and sensitive data collection.

  2. Your disclosure must accompany and immediately precede a request for user consent. You must not begin collection prior to obtaining affirmative consent. The request for consent:

    1. Must present the consent dialog in a clear and unambiguous way;
    2. Must require affirmative user action (for example, tap to accept, tick a check-box, a verbal command, etc.) in order to accept;
    3. Must not interpret navigation away from the disclosure (including tapping away or pressing the back or home button) as consent; and,
    4. Must not utilize auto-dismissing or expiring messages.

  3. You must provide user help documentation that explains how users can manage and delete their data from your app or service.

Limited use of user data

Upon accessing Workspace APIs for an appropriate use, your use of the data obtained must comply with the below requirements. These requirements apply to data derived from both Sensitive and Restricted scopes.

  1. Limit your use of data to providing or improving your appropriate use case or features that are visible and prominent in the requesting application's user interface.

  2. Transfers of data are not allowed, except:

    1. To provide or improve your appropriate use case or user-facing features that are visible and prominent in the requesting application's user interface and only with the user's consent;
    2. For security purposes (for example, investigating abuse);
    3. To comply with applicable laws and/or regulations; or,
    4. As part of a merger, acquisition or sale of assets of the developer after obtaining explicit prior consent from the user.

  3. Do not allow humans to read user data, unless:

    1. You have obtained and documented the user's explicit consent to read specific data (for example, helping a user re-access the product or a service after having lost their password);
    2. The data (including derivations) is aggregated and anonymized and used for internal operations in accordance with applicable privacy and other jurisdictional legal requirements;
    3. It's necessary for security purposes (for example, investigating abuse); or,
    4. To comply with applicable laws and/or regulations.

All other transfers, uses, or sale of user data is completely prohibited, including:

  1. Transferring or selling user data to third parties like advertising platforms, data brokers, or any information resellers.
  2. Transferring, selling, or using user data for serving ads, including retargeting, personalized or interest-based advertising.
  3. Transferring, selling, or using user data to determine credit-worthiness or for lending purposes.
  4. Transferring, selling, or using user data to create, train, or improve a machine learning or artificial intelligence model beyond that specific user’s personalized model for the appropriate use case or user-facing feature.

An affirmative or other similar statement that your use of the data complies with the Limited Use restrictions must be disclosed in your application or on a website belonging to your web-service or application; for example, a link on a homepage to a dedicated page or privacy policy noting: "The use of information received from Workspace APIs will adhere to the Google User Data Policy, including the Limited Use requirements."

Maintain a secure operating environment

Treat all user data securely in transit and at rest. Take reasonable and appropriate steps to protect all applications or systems that make use of the Workspace APIs and any data derived from it against unauthorized or unlawful access, use, destruction, loss, alteration, or disclosure.

Applications accessing Restricted Scopes must demonstrate that they adhere to certain security practices.

Recommended security practices include implementing and maintaining an Information Security Management System such as outlined in ISO/IEC 27001 and ensuring your application or web service is robust and free from common security issues as set out by the OWASP Top 10.

Required security measures include:

  1. Using an industry accepted encryption standard to encrypt user data that is:

    1. Stored on portable devices or portable electronic media;
    2. Maintained outside of Google's or your systems;
    3. Transferred across any external network not solely managed by you; and,
    4. At rest on your systems.

  2. Transmitting data using secure modern protocols (for example, over HTTPS).

  3. Keeping user data and credentials, specifically tokens such as OAuth access and refresh tokens, encrypted at rest.

  4. Ensuring keys and key material are managed appropriately, such as stored in a hardware security module or equivalent-strength key management system.

Required security measures for Restricted Scopes also include following the Cloud Application Security Assessment (CASA). In addition, depending on the API being accessed and number of user grants or users, we may also require that your application or service undergo a periodic security assessment and obtain a Letter of Assessment from a Google-designated third party.

You agree to promptly notify Google at [email protected] of any known or suspected unauthorized access to the systems, networks, accounts, or other locations where Google Data is stored ("Security Incident"). You agree to cooperate fully with Google to correct any known or suspected Security Incident, and in any such event, to notify Google at [email protected] before you make any public statements regarding any known or suspected Security Incident.

Restricted scopes

Workspace Restricted scopes include:

  1. Any Gmail API scope that permits an application to:

    1. Read, create, or modify message bodies (including attachments), metadata, or headers; or
    2. Control mailbox access, email forwarding, or admin settings.

  2. Any Google Drive API scope that permits an application to:

    1. Read, modify, or manage the content or metadata of a user's Drive files, without the user individually granting file-by-file access.

  3. Any Google Chat API scope that permits an application to:

    1. Read, modify, or manage the content or metadata of a user's Chat messages.

For more details, see the list of Restricted Scopes.