Dr. Zepf.com Uses Google API Services to
Book/Schedule Appointments and Services
Google API Services User Data Policy
Last updated August 22, 2022
Google API Services, including Google Sign-In, are part of an authentication and authorization framework that gives you, the developer, the ability to connect directly with Google users when you would like to request access to Google user data. The policy below, as well as the Google APIs Terms of Service, govern the use of Google API Services when you request access to Google user data. Please check back from time to time as these policies are occasionally updated.
Accurately represent your identity and intent
If you wish to access Google user data you must provide Google users and Google with clear and accurate information regarding your use of Google API Services. This includes, without limitation, requirements to accurately represent:
- Who is requesting Google user data? All permission requests must accurately represent the identity of the application that seeks access to user data. If you have obtained authorized client credentials to access Google API Services, keep these credentials confidential.
- Why are you requesting Google user data? Be honest and transparent with users when you explain the purpose for which your application requests user data. If your application requests data for one reason but the data will also be utilized for a secondary purpose, you must notify Google users of both use cases. As a general matter, users should be able to readily understand the value of providing the data that your application requests, as well as the consequences of sharing that data with your application.
Be transparent about the data you access with clear and prominent privacy disclosures
Request the minimum relevant permissions
Permission requests should make sense to users, and should be limited to the critical information necessary to implement your application.
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.
Deceptive or unauthorized use of Google API Services is prohibited
You are strictly prohibited from engaging in any activity that may deceive users or Google about your use of Google API Services. This includes without limitation the following requirements:
Do not misrepresent what data is collected or what you do with Google user data. Be up front with users so that they can make an informed decision to grant authorization. You must disclose all user data that you access, use, store, delete, or share, as well as any actions you take on a user’s behalf.
You are not permitted to access, aggregate, or analyze Google user data if the data will be displayed, sold, or otherwise distributed to a third party conducting surveillance.
Overall there should be no surprises for Google users: hidden features, services, or actions that are inconsistent with the marketed purpose of your application may lead Google to suspend your ability to access Google API Services.
Do not mislead Google about an application’s operating environment. You must accurately represent the environment in which the authentication page appears. For example, don’t claim to be an Android application in the user agent header if your application is running on iOS, or represent that your application’s authentication page is rendered in a desktop browser if instead the authentication page is rendered in an embedded web view.
Do not use undocumented APIs without express permission. Don’t reverse engineer undocumented Google API Services or otherwise attempt to derive or use the underlying source code of undocumented Google API Services. You may only access data from Google API Services according to the means stipulated in the official documentation of that API Service, as provided on Google’s Developer Page.
Do not make false or misleading statements about any entities that have allegedly authorized or managed your application. You must accurately represent the company, organization, or other authority that manages your application. Making false representations about client credentials to Google or Google users is grounds for suspension.
The Children’s Online Privacy Protection Act, or COPPA, applies to websites, apps, and services directed to children under the age of 13 and general audience apps, websites, or services with users known to be under the age of 13. While child-directed apps may use some Google services, developers are responsible for using these services according to their obligations under the law. Please review the FTC’s guidance on COPPA (including information about the differences between mixed audience apps and apps directed primarily to children from the FTC’s website) and consult with your own legal counsel.
Child-directed apps: If your application is directed primarily at children, it should not use Google Sign-In or any other Google API Service that accesses data associated with a Google Account. This restriction includes Google Play Games Services and any other Google API Service using the OAuth technology for authentication and authorization.
Mixed audience apps: Applications that are mixed audience shouldn’t require users to sign in to a Google Account, but can offer, for example, Google Sign-In or Google Play Games Services as an optional feature. In these cases, users must be able to access the application in its entirety without signing into a Google Account.
Maintain a secure operating environment
We expect all user data is secure in transit and at rest. Take reasonable and appropriate steps to protect all applications or systems that make use of Google API Service and any data derived from it against unauthorized or unlawful access, use, destruction, loss, alteration, or disclosure.
Additional Requirements for Specific API Scopes
Certain Google OAuth API Scopes (the “Sensitive and Restricted Scopes”) are subject to additional requirements that can be found in each product’s User Data and Developer Policy or the Google Developer Page. More information about the requirements to obtain (or keep) access to these scopes is also available in the OAuth Application Verification FAQ.
Note: If your app is only used by users within your own domain, then these requirements do not apply. Google Workspace can control access to connected applications via allowlisting. Learn more about best practices for managing your enterprise OAuth ecosystem.
Additional requirements include:
Appropriate Access: Developers may only request access to the scopes for a permitted Application Type described by the product. Such application types can be found under an Appropriate Access heading in the product specific policy or the product’s Google Developer Page.
Limited Use: Your use of data obtained via the product’s specified scopes must comply with the below requirements. These requirements apply to the raw data obtained from the scopes and data aggregated, anonymized, or derived from them.
Limit your use of data to providing or improving user-facing features that are prominent in the requesting application’s user interface;
Transfers of data are not allowed, except:
- To provide or improve your appropriate access or user-facing features that are visible and prominent in the requesting application’s user interface and only with the user’s consent;
- For security purposes (for example, investigating abuse);
- To comply with applicable laws; or,
- As part of a merger, acquisition, or sale of assets of the developer after obtaining explicit prior consent from the user.
Don’t allow humans to read the data, unless:
- You first obtained the user’s affirmative agreement to view specific messages, files, or other data, with the limited exception of use cases approved by Google under additional terms applicable to the Nest Device Access program;
- It is necessary for security purposes (for example, investigating a bug or abuse);
- It is necessary to comply with applicable law; or
- The data (including derivations) is aggregated and used for internal operations in accordance with applicable privacy and other jurisdictional legal requirements.
All other transfers, uses, or sales of user data are prohibited, including:
- Transferring or selling user data to third parties like advertising platforms, data brokers, or any information resellers.
- Transferring, selling, or using user data for serving ads, including retargeting, personalized or interest-based advertising.
- Transferring, selling, or using user data to determine credit-worthiness or for lending purposes.
You must ensure that your employees, agents, contractors, and successors comply with this Google API Services User Data Policy.
Secure Data Handling: Applications accessing the product specified scopes (the “Sensitive and Restricted Scopes”) must demonstrate that they adhere to certain security practices. Depending on the API being accessed and number of user grants or users, applications must pass an annual security assessment and obtain a Letter of Assessment from a Google-designated third party. More information about the assessment requirements to obtain or keep access to the scopes is also available in the OAuth Application Verification FAQ and the product’s Google Developer Page.
You must access Google API Services in accordance with the Google APIs Terms of Service. If you are found to be out of compliance with the Google APIs Terms of Service, this Google API Services: User Data Policy, or any Google product policies that are applicable to the Google API Service you are using, Google may revoke or suspend your access to Google API Services and other Google products and services if you are found in violation of other product policies, terms of service, or other guidelines. Your access to Google API Services may also be revoked if your application enables end-users or other parties to violate the Google APIs Terms of Service and/or Google policies.
We are pleased to license much of the documentation on Google Developers under terms that explicitly encourage people to take, modify, reuse, re-purpose, and remix our work as they see fit.
You will find the following notice at the bottom of many pages on the Google Developers website:
When you see a page with this notice you are free to use nearly everything on the page in your own creations. For example, you could quote the text in a book, cut-and-paste sections to your blog, record it as an audiobook for the visually impaired, or even translate it into Swahili. Really. That’s what open content licenses are all about. We just ask that you give us attribution when you reuse our work.
You may also find the following notice on the bottom of some pages:
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see our Site Policies.
When you see this notice, you are free to use the content, and in addition you are free to use the computer source code that appears in the content (such as in examples) in the code of your own projects.
What is not licensed?
We say “nearly everything” as there are a few simple conditions that apply.
Google’s trademarks and other brand features are not included in this license. Please see our standard guidelines for third-party use of Google brand features for information about this usage.
In some cases, a page may include content consisting of images, audio or video material, or a link to content on a different webpage (such as videos or slide decks). This content is not covered by the license, unless specifically noted.
Proper attribution is required when you reuse or create modified versions of content that appears on a page made available under the terms of the Creative Commons Attribution license. The complete requirements for attribution can be found in section 3 of the Creative Commons legal code.
In practice we ask that you provide attribution to Google to the best of the ability of the medium in which you are producing the work.
There are several typical ways in which this might apply:
If your online work exactly reproduces text or images from this site, in whole or in part, please include a paragraph at the bottom of your page that reads:
Also, please link back to the original source page so that readers can refer to it for more information.
If your online work shows modified text or images based on the content from this site, please include a paragraph at the bottom of your page that reads:
Again, please link back to the original source page so that readers can refer to it for more information. This is even more important when the content has been modified.
If you produce non-hypertext works, such as books, audio, or video, we ask that you make a best effort to include a spoken or written attribution in the spirit of the messages above.