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.

Acceptable use policies

Use of Google Photos APIs is governed by the Google API Services User Data Policy. Read this policy closely before requesting user data. In addition to the Google Photos User Content and Conduct Policy, 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 and using 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 and Terms of Service?

Use the Google Photos logo only as prescribed in the UX guidelines and Terms of Service. 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 or album IDs, 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.
  2. Use the correct OAuth flow for your app:
  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.