Using API Keys

This guide shows how to create API keys, and how to set up API key restrictions.

API keys are a simple encrypted string that can be used when calling certain APIs that don't need to access private user data. API keys are useful in clients such as browser and mobile applications that don't have a backend server. The API key is used to track API requests associated with your project for quota and billing.

API keys have important limitations, such as:

Because of this we recommend using the standard authentication flow instead. However, there are limited cases where API keys are more appropriate. For example, if you're developing a mobile application that needs to use the Google Cloud Translation API, but doesn't otherwise need a backend server, API keys are the simplest way to authenticate to that API. In most cases, we recommend having your application communicate to a backend server that handles authenticating to, and calling, Google Cloud Platform services.

Creating an API key

  1. Navigate to the APIs & Services→Credentials panel in Cloud Platform Console.

  2. Select Create credentials, then select API key from the dropdown menu.

    Add API key

  3. Click the Create button. The API key created dialog box displays your newly created key.

You might want to copy your key and keep it secure. Unless you are using a testing key that you intend to delete at a later time, we recommend you add an API key restriction.

Using an API key

Pass the API key into a REST API call as a query parameter with the following format. Replace API_KEY with your API key,

key=API_KEY

For example, to pass an API key for a Cloud Natural Language API request for documents.analyzeEntities:

POST https://language.googleapis.com/v1/documents:analyzeEntities?key=API_KEY

Securing an API key

When you use API keys in your applications, take care to keep them secure. Publicly exposing your credentials can result in your account being compromised, which could 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, if you 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 API key restrictions to be used by only the IP addresses, referrer URLs, and mobile apps that need them.

  • 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.

Adding restrictions to API keys

An API key is unrestricted by default. Unrestricted keys are insecure because they can be viewed publicly, such as from within a browser, or they can be accessed on a device where the key resides. To help secure your key, we recommend you add a restriction.

To add a restriction:

  1. Click Restrict key within the API key created dialog box. The API key configuration panel appears:

    Add API key restriction

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

    • API clients running on a web browser should add an HTTP referrers restriction 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.

    • API clients running on a backend server that can't support service accounts should add an IP addresses restriction to guard against usage from clients at different IP addresses.

    • Android applications should add an Android apps restriction, and add your package name and SHA-1 signing-certificate fingerprint.

    • iOS applications should add an iOS apps restriction, and add any iOS bundle identifiers to restrict API calls to these iOS bundles.

For testing, you might not want to place any restriction at all. However, we recommend that you either add a restriction to this key, or delete the restriction after you deploy your application to production.

What's next

Monitor your resources on the go

Get the Google Cloud Console app to help you manage your projects.

Send feedback about...

Documentation