Google API Keys Usage and Admins

Table of Contents

Using API Keys

*Google Sheets API can be used in Advanced Data Table.

How To Integrate Google Sheets with Advanced Data Table #

See Advanced Data Table

When you use API keys in your applications, ensure that they are kept secure during both storage and transmission. Publicly exposing your API keys can lead to unexpected charges on your account. To help keep your API keys secure, follow these best practices:

  • Do not embed API keys directly in code. API keys that are embedded in code can be accidentally exposed to the public. For example, you may forget to remove the keys from code that you share. Instead of embedding your API keys in your applications, store them in environment variables or in files outside of your application’s source tree.
  • Do not store API keys in files inside your application’s source tree. If you store API keys in files, keep the files outside your application’s source tree to help ensure your keys do not end up in your source code control system. This is particularly important if you use a public source code management system such as GitHub.
  • Set up application and API key restrictions. By adding restrictions, you can reduce the impact of a compromised API key.
  • Delete unneeded API keys to minimize exposure to attacks.
  • Regenerate your API keys periodically. You can regenerate API keys from the Credentials page by clicking Regenerate key for each key. Then, update your applications to use the newly-generated keys. Your old keys will continue to work for 24 hours after you generate replacement keys.
  • Review your code before publicly releasing it. Ensure that your code does not contain API keys or any other private information before you make your code publicly available.

 

API keys are unrestricted by default. Unrestricted keys are insecure because they can be used by anyone from anywhere. For production applications, you should set both application restrictions and API restrictions.

To add API key restrictions:

  1. Navigate to the APIs & Services→Credentials panel in Cloud Console.
  2. Select the name of an existing API key.

Application restrictions specify which web sites, IP addresses, or apps can use an API key. Add application restrictions based on your application type. You can only set one restriction type per API key.

Choose the restriction type based on the needs of your application.

  • Use None for testing purposes only.
  • Use HTTP referrers for API clients that run on a web browser, so that only the specified pages can call the API. These types of applications expose their API keys publicly, so we recommend using a service account instead. See the Adding HTTP restrictions section below for examples.
  • Use IP addresses to limit API key access to certain IP addresses.
  • Use Android apps for Android applications. This option requires adding your package name and SHA-1 signing-certificate fingerprint. For more information, see Adding Android restrictions in the API key documentation.
  • Use iOS apps for iOS applications. This option requires adding at least one iOS bundle identifier to restrict API calls to specific iOS bundles.

API keys used by web applications should have HTTP restrictions. To add HTTP restrictions:

  • Select HTTP referrers (web sites) in the Application restrictions section.
  • Input at least one restriction in the Website restrictions section.
  • If your domain supports both HTTP and HTTPS, both restrictions must be added separately.
  • You can optionally use wildcard characters (*) for the subdomain and/or path.

The following table shows example scenarios and restrictions, from most restrictive to least restrictive. We recommend using the most restrictive example that fits your use case.

Scenario Restrictions
Allow a specific URL. Add a single restriction with an exact path. For example:

  • https://www.example.com/path
  • https://www.example.com/path/path
Allow any URL in a single subdomain or naked domain. You must set at least two restrictions to allow an entire domain.

  1. Set a restriction for the domain, without the trailing slash. For example:
    • https://www.example.com
    • https://sub.example.com
    • https://example.com
  2. Set a second restriction for the domain that includes a wildcard for the path. For example:
    • https://www.example.com/*
    • https://sub.example.com/*
    • https://example.com/*
  3. If your domain allows both HTTP and HTTPS you must add additional restrictions separately.
Allow any subdomain URLs in a single domain. You must set at least two restrictions.

  1. Set a restriction for the domain, with a wildcard for the subdomain, and without the trailing slash. For example:
    • https://*.example.com
  2. Set a second restriction for the domain that includes a wildcard for the path, such as:
    • https://*.example.com/*
  3. If your domain allows both HTTP and HTTPS you must add additional restrictions separately.

API restrictions specify which APIs can be called using the API key. All API keys used by production applications should have API restrictions.

To set API restrictions:

  1. In the API restrictions section, click Restrict key .
  2. Select all APIs from the dropdown that your API key will be used to access.
  3. Click Save.

You can create 300 API keys per project. This is a system limit, and cannot be changed using a quota increase request.

If more API keys are needed, they should be shared across multiple projects.

Usage limits #

As the Google Sheets API is a shared service, we apply quotas and limitations to make sure it’s used fairly by all users and to protect the overall health of the Google Workspace system.

If you exceed a quota, you’ll generally receive a 429: Too many requests HTTP status code response. If this happens, you should use an exponential backoff algorithm and try again later. Provided you stay within the per-minute quotas below, there’s no limit to the number of requests you can make per day.

The following table details the request limits:

Quotas
Read requests
Per day per project Unlimited
Per minute per project 300
Per minute per user per project 60
Write requests
Per day per project Unlimited
Per minute per project 300
Per minute per user per project 60

 

Powered by BetterDocs