# Acceptable use policies and requirements All integrations with Google Photos APIs must comply with the policies and requirements documented on this page.
## Review checklist Use the following checklist to review all policies and requirements needed to prepare your app for review from the Google Photos team. Have you followed the policies governing Google Photos APIs? ([Policies](https://developers.google.com/photos/library/legacy/guides/acceptable-use#policies)) Did you build something new, beyond creating a substitute for Google Photos? ([AUP-1](https://developers.google.com/photos/library/legacy/guides/acceptable-use#solve-problems)) Does your app follow the [UX guidelines](https://developers.google.com/photos/library/guides/ux-guidelines) and [Terms of Service](https://developers.google.com/terms)? ([AUP-2](https://developers.google.com/photos/library/legacy/guides/acceptable-use#copyrights)) Do you let your users know what data you are requesting and why? ([AUP-3](https://developers.google.com/photos/library/legacy/guides/acceptable-use#permission)) Do you minimize the data you need to access and store? ([AUP-4](https://developers.google.com/photos/library/legacy/guides/acceptable-use#minimize-access)) Does your app utilize and store credentials securely? ([AUP-5](https://developers.google.com/photos/library/legacy/guides/acceptable-use#credential-security)) Do you keep your system up-to-date and patch known vulnerabilities in a timely manner? ([AUP-6](https://developers.google.com/photos/library/legacy/guides/acceptable-use#up-to-date)) ## Acceptable use policies Use of Google Photos APIs is governed by the [Google API Services User Data Policy](https://developers.google.com/terms/api-services-user-data-policy). Read this policy closely before requesting user data. In addition to the [Google Photos User Content and Conduct Policy](https://support.google.com/photos/answer/9292998), your application and its users must also comply with other requirements in this document. ## Detailed explanation of requirements ### AUP-1: Solve problems and innovate, don't duplicate *Did you build something new, beyond creating a substitute for Google Photos?* Google Photos is for storing, enjoying, and sharing personal memories. Your new app/integration should add something to Google Photos' core functionality, not just recreate it. Keep the following points in mind when designing and building your integration: - Do not use Google Photos APIs to store or serve media such as photos or videos that are not of a personal nature. For storing internal enterprise data or hosting website media, consider [learning about](https://cloud.google.com/storage/docs/introduction) and [using](https://cloud.google.com/storage/docs/discover-object-storage-console) Google Cloud Storage. - Do not use data from Google Photos APIs for advertising purposes, including personalized, re-targeted, interest-based advertising, and advertising measurement. - Do not make a substitute for Google Photos. For example, do not use this API to create a general purpose photo gallery app. - Do not use this API to create, train, or improve (directly or indirectly) similar or competing products or services. ### AUP-2: Respect Google's copyrights and attribution *Does your app follow the [UX guidelines](https://developers.google.com/photos/library/guides/ux-guidelines) and [Terms of Service](https://developers.google.com/terms)?* Use the Google Photos logo only as prescribed in the [UX guidelines](https://developers.google.com/photos/library/legacy/guides/ux-guidelines) and [Terms of Service](https://developers.google.com/terms). Do not imply endorsements or a stronger connection than really exists between your app and Google. ### AUP-3: Always ask permission *Do you let your users know what data you are requesting and why?* You must let users know what data you are requesting and why. Do not access, cache, copy, analyze, or perform any action involving user data unless expressly permitted by the content owner (for example, when a user picks a specific photo to copy into a blog post). In general, unless absolutely critical to your product's functionality, media should only be presented in your UI and downloaded by the end user's device. Data migration tools that help users copy their media between services are only permitted if the transfer is done with the user's explicit permission and no data is stored or analyzed by any intermediary service. In all other cases, bulk processing of media is not permitted. ### AUP-4: Minimize data access and storage *Do you minimize the data you need to access and store?* You must not cache or copy user data without the content owner's permission. If you need to copy or cache media for performance reasons, including thumbnails, you must only do so temporarily and for no longer than 60 minutes. We recognize that some use cases (for example, copying photos to a blog post) might require longer term access to data. In such cases, you must adhere to the following requirements: 1. The user must explicitly choose the specific media items to which you are granted access. 2. You must delete a user's data within 60 days of a request to do so. As an alternative to longer term data access, consider storing [media item IDs](https://developers.google.com/photos/library/legacy/guides/access-media-items) or [album IDs](https://developers.google.com/photos/library/legacy/guides/manage-albums), and using the Google Photos Library API to dynamically load the relevant data. ### AUP-5: Utilize and store credentials securely *Does your app utilize and store credentials securely?* Take reasonable and appropriate steps to protect user data against unauthorized or unlawful access. 1. Follow all [Google OAuth 2.0 Policies](https://developers.google.com/identity/protocols/oauth2/policies). 2. Use the correct OAuth flow for your app: - For client-side native apps (or web apps with native OS API support), use the [normal OAuth 2.0 flow](https://developers.google.com/identity/protocols/oauth2/native-app). Do not use the [limited-input device flow](https://developers.google.com/identity/protocols/oauth2/limited-input-device). - For pure in-browser web apps, choose one of the following: - Use the [Client-side Web App flow](https://developers.google.com/identity/protocols/oauth2/javascript-implicit-flow) without saving user credentials. - Use the [Server-side Web App flow](https://developers.google.com/identity/protocols/oauth2/web-server) to protect user credentials in the backend. 3. Use HTTPs for redirect URIs and JavaScript origins. 4. Permanently delete revoked tokens from the application/system. 5. Encrypt tokens in transit and at rest. 6. For client-side native apps (or web apps with native OS API support), credentials may only be stored using one of the following solutions: - Android: Keystore - iOS / MacOS: Keychain Services - WebOS: Account Manager - Tizen: Key Manager - Windows 8, 10, 11: Credential Locker - Linux: System keyring (e.g. Kernel keyring or GNOME keyring). ### AUP-6: Keep your system up-to-date *Do you keep your system up-to-date and patch known vulnerabilities in a timely manner?* Keep your stack up-to-date, and patch all known vulnerabilities in a timely manner. 1. If your integration is client-side or has a client component, require users to update. - Do not allow clients to utilize functionality after 90 days out-of-date. - Permanently expire/delete tokens on clients after 180 days out-of-date. 2. Remote Code Execution (RCE) and Privilege Escalation (PE) vulnerabilities must be patched within 30 days.