Click here to see your recently viewed pages and most viewed pages.
Hide
Google Developers Console Help

The Google Developers Console is Google's new developer experience for managing and viewing traffic data, authentication, and billing information for the Google APIs that your projects use.

Contents

  1. Managing projects in the Developers Console
    1. Creating and deleting projects
    2. Project ID and project number
    3. Managing project members
  2. Activating or deactivating APIs
  3. Credentials, access, security, and identity
  4. Setting up OAuth 2.0
    1. User consent
    2. Service accounts
    3. Installed applications
  5. API keys
    1. Best practices for securely using API keys
  6. Monitoring, filtering, and capping usage
    1. Filtering usage
    2. Capping usage
  7. Billing

Managing projects in the Developers Console

In the Google Developers Console, a project is a collection of settings, credentials, and metadata about the application or applications you're working on that make use of Google Developer APIs and Google Cloud resources. The Developers Console is where you manage these aspects of your project, such as generating API credentials, activating APIs, and managing team and billing information associated with your project.

Creating and deleting projects

You can use one Developers Console project to manage all of your work, or you can create multiple projects, depending on your development and collaboration needs. Consider whether you're collaborating with a different set of people, want to track usage differently, or need to set different traffic controls for different parts of your work. If so, breaking up your work into multiple projects might make sense. That said, you cannot use multiple projects to try to exceed API usage limits.

Creating a project

To create a project, do the following:

Go to the Google Developers Console. Click Create Project, enter a name and a project ID, or accept the defaults, and click Create.

Deleting a project

Deleting a project from the Developers Console releases all resources used within the project. Only project owners can delete or restore projects.

To delete a project, do the following:

  1. Go to the Google Developers Console.
  2. Select a project.
  3. In the sidebar on the left, select Billing & Settings.
  4. Click Delete project. A confirmation screen describing what will happen appears.
  5. To confirm, enter your project ID and click Delete project.

Deleting a project stops all billing and traffic serving, deletes any App Engine applications, and terminates all Compute Engine instances. All data associated with Google Cloud services become inaccessible.

After a 7-day waiting period, the project and associated data are permanently deleted from the Developers Console.

Note that after the 7-day waiting period ends, the time it takes to completely delete a project may vary. For example, if a project has billing set up, it may not be completely deleted until the current billing cycle ends, you receive the next bill, and your account is successfully charged. Additionally, the number and types of services in use may also affect when the system permanently deletes a project.

Restoring deleted projects

Project owners can restore a deleted project within the 7-day waiting period that starts when the project was deleted. Restoring a project returns it to the state it was in prior to deletion.

To restore a project as a project owner, do the following:

  1. Go to the Google Developers Console.
  2. Below the list of projects, click Projects pending deletion.
  3. Check the box for the project you wish to restore, and click Restore.

Project ID and project number

There are two ways to identify your project:

  • The project ID is a unique identifier for a project and is used only within the Developers Console. When you first create a project, you may accept the default generated project ID or choose your own. A project ID cannot be changed after the project is created, so choose an ID that you'll be comfortable using for the lifetime of the project.

    To determine your project ID, do the following:

    1. Go to the Google Developers Console.
    2. Find and select your project in the table on the main landing page.
    3. The project ID appears at the top of the project overview page.

  • The project number is automatically assigned by the Google Developers Console when you create a project.

    To determine your project number, do the following:

    1. Go to the Google Developers Console.
    2. Select a project, or create a new one.
    3. The project number appears at the top of the project's overview page.

Managing project members

The creator of a given project is granted owner-level permissions and can grant owner-level permissions to other project members. All members with owner-level permissions are also project owners, and are allowed to manage all aspects of a project including deleting the project.

Project owners can also add and remove other project members and edit their permission settings. Project owners can add an email address that represents a group, thereby sharing the project with all members of that group, but every project must have at least one project member that is an individual.

Note: Google App Engine currently only supports collaboration with individuals, not groups. While you may still share your project with a group, only collaborators added as individuals can use functionality related to Google App Engine.

To add a project member, do the following:

  1. Go to the Google Developers Console.
  2. Select a project, or create a new one.
  3. In the sidebar on the left, click Permissions.
  4. Click Add Member and provide an email address that's associated with a Google Account.

You must provide an email address that is associated with a Google Account. If the email address belongs to an individual, adding it triggers an invitation flow and the new project member must accept the invitation before they can access the project. If the email address belongs to a group, the group is added right away, with no invitation step.

Project owners may manage permission settings and membership for project members and service accounts from the same Permissions page. To manage permissions, click the dropdown box in the Permission column and select a new permission level. The new permission level is saved automatically.

To delete a project member, check the box next to their email address and click Remove at the top of the page.

Activating and deactivating APIs

Activating an API associates it with the current project, adds monitoring pages, and enables billing for that API if billing is enabled for the project.

To activate an API for your project, do the following:

  1. Go to the Google Developers Console.
  2. Select a project, or create a new one.
  3. In the sidebar on the left, expand APIs & auth.
  4. Click APIs to view the API Library, which lists all available APIs. The APIs are grouped by product family and popularity. If the API you want to activate isn't visible in the list, then use search to find it.
  5. Select the API you want to activate, then select the Enable API button.

After you have enabled an API, use the Enabled APIs link in the Console's API section to see a list of all your enabled APIs. From the list, you can disable and re-enable an API. Some APIs prompt you to accept their Terms of Service before you can activate them.

Note that some APIs are in preview mode, meaning that they require special signup and whitelisting before you can try them out.

You can deactivate an API for a project whenever you want, although any pending fees will still be charged to your account. For more information, see the Billing section.

Credentials, access, security, and identity

Each request to an API that is represented in the Google Developers Console must include a unique identifier. Unique identifiers enable the Developers Console to tie requests to specific projects in order to monitor traffic, enforce quotas, and handle billing.

Google supports two mechanisms for creating unique identifiers:

OAuth 2.0 client IDs
For applications that use the OAuth 2.0 protocol to call Google APIs, you can use an OAuth 2.0 client ID to generate an access token. The token contains a unique identifier.
API keys
An API key (either a server key or a browser key) is a unique identifier that you generate using the Developers Console. Using an API key does not require user action or consent. API keys do not grant access to any account information, and are not used for authorization.

Use an API key when your application is running on a server and accessing one of the following kinds of data:

  • Data that the data owner has identified as public, such as a public calendar or blog.
  • Data that is owned by a Google service such as Google Maps or Google Translate. (Access limitations may apply.)

If you are only calling APIs that do not require user data, such as the Google Custom Search API, then API keys might be simpler to use than OAuth 2.0 access tokens. However, if your application already uses an OAuth 2.0 access token, then there is no need to generate an API key as well. Google ignores passed API keys if a passed OAuth 2.0 access token is already associated with the corresponding project.

Setting up OAuth 2.0

To use OAuth 2.0 in your application, you need an OAuth 2.0 client ID, which your application uses when requesting an OAuth 2.0 access token. To create an OAuth 2.0 client ID in the Google Developers Console, do the following:

  1. Go to the Google Developers Console.
  2. Select a project, or create a new one.
  3. In the sidebar on the left, expand APIs & auth. Next, click APIs. Select the Enabled APIs link in the API section to see a list of all your enabled APIs. Make sure that the API is on the list of enabled APIs. If you have not enabled it, select the API from the list of APIs, then select the Enable API button for the API.
  4. In the sidebar on the left, select Credentials.
  5. Click Create new Client ID.
  6. Select the appropriate Application Type for your project and enter any additional information required. If this is your first time creating a client ID, besides being able to select your application type, you can configure your consent screen by clicking the Consent Screen button. You will not get a prompt to configure your consent screen again after you do it the first time.
  7. Click Create Client ID

To deactivate the client ID, click the Delete button below the appropriate table on the Credentials page.

User consent

When you use OAuth 2.0 for authentication, your users are authenticated after they agree to terms presented to them on a user consent screen.

To set up your project's consent screen, do the following:

  1. Go to the Google Developers Console.
  2. Select a project, or create a new one.
  3. In the sidebar on the left, expand APIs & auth. Next, click APIs. Select the Enabled APIs link in the API section to see a list of all your enabled APIs. Make sure that the API is on the list of enabled APIs. If you have not enabled it, select the API from the list of APIs, then select the Enable API button for the API.
  4. In the sidebar on the left, select Consent screen.
  5. Fill out the form and click Save.

For more information about user authentication, see the OAuth 2.0 documentation.

Service accounts

If your project employs server-to-server interactions such as those between a web application and Google Cloud Storage, then you need a private key and other service-account credentials. To generate these credentials, or to view the email address and public keys that you've already generated, do the following:

  1. Go to the Google Developers Console.
  2. Select a project, or create a new one.
  3. In the sidebar on the left, expand APIs & auth. Next, click APIs. Select the Enabled APIs link in the API section to see a list of all your enabled APIs. Make sure that the API is on the list of enabled APIs. If you have not enabled it, select the API from the list of APIs, then select the Enable API button for the API.
  4. In the sidebar on the left, select Credentials.
  5. To set up a new service account, do the following:

    1. Under the OAuth heading, select Create new Client ID.
    2. When prompted, select Service Account and click Create Client ID.
    3. A dialog box appears. To proceed, click Okay, got it.

    Your new Public/Private key pair is generated and downloaded to your machine; it serves as the only copy of this key. You are responsible for storing it securely. The Console shows your private key's password only at this initial moment of service account creation--the password will not be shown again. You now have Generate New JSON Key and Generate New P12 Key options, and the ability to delete.

Your project needs the private key when requesting an OAuth 2.0 access token in server-to-server interactions. Google does not keep a copy of this private key, and this screen is the only place to obtain this particular private key. When you click Download private key, the PKCS #12-formatted private key is downloaded to your local machine. As the screen indicates, you must securely store this key yourself.

The name of the downloaded private key is the key's thumbprint. When inspecting the key on your computer, or using the key in your application, you need to provide the password notasecret. Note that while the password for all Google-issued private keys is the same (notasecret), each key is cryptographically unique.

You can generate multiple public-private key pairs for a single service account. This makes it easier to update credentials or roll them over without application downtime. However, you cannot delete a key pair if it is the only one created for that service account.

Use the email address when granting the service account access to supported Google APIs.

For more details, see the OAuth 2.0 Service Accounts documentation.

Installed applications

If your application is to be installed on a device or computer (such as a system running Microsoft Windows, Apple OS X, Apple iOS, or Android), you can use either of two OAuth 2.0 flows, as described in Google's OAuth 2.0 Installed Applications and Devices documentation.

Chrome

Google Chrome apps and extensions are a special case of installed applications. Chrome exposes JavaScript APIs to allow your Chrome apps and extensions to perform various operations. Some of these APIs rely on knowing the identity of the user who's signed in to Chrome. If you're writing a Chrome app or extension that calls APIs that need to know the user's identity, and you want your app or extension to get user authorization for these requests using OAuth 2.0, then choose Chrome as the platform when you create your credentials. You will need to enter your Chrome app or extension's Application ID. For more information about these APIs, see the Google Chrome Identity API documentation.

Android

Note: Currently, obtaining OAuth 2.0 access tokens via AccountManager works for Android Ice Cream Sandwich (4.0) and Jelly Bean (4.1).

To obtain the appropriate credentials for an Android application in the Google Developers Console, choose Android when prompted to select a platform.

If your application accesses APIs directly from Android (as opposed to from a web server), then in order to register your digitally signed .apk file's public certificate in the Developers Console, you will need your Android package name and SHA-1 fingerprint.

The following procedure describes all necessary steps:

In a terminal, run the Keytool utility to get the SHA1 fingerprint for your digitally signed .apk file's public certificate.
keytool -exportcert -alias androiddebugkey -keystore path-to-debug-or-production-keystore -list -v

The Keytool prints the fingerprint to the shell. For example:

$ keytool -exportcert -alias androiddebugkey -keystore ~/.android/debug.keystore -list -v
Enter keystore password: Type "android" if using debug.keystore
Alias name: androiddebugkey
Creation date: Aug 27, 2012
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=Android Debug, O=Android, C=US
Issuer: CN=Android Debug, O=Android, C=US
Serial number: 503bd581
Valid from: Mon Aug 27 13:16:01 PDT 2012 until: Wed Aug 20 13:16:01 PDT 2042
Certificate fingerprints:
   MD5:  1B:2B:2D:37:E1:CE:06:8B:A0:F0:73:05:3C:A3:63:DD
   SHA1: D8:AA:43:97:59:EE:C5:95:26:6A:07:EE:1C:37:8E:F4:F0:C8:05:C8
   SHA256: F3:6F:98:51:9A:DF:C3:15:4E:48:4B:0F:91:E3:3C:6A:A0:97:DC:0A:3F:B2:D2:E1:FE:23:57:F5:EB:AC:13:30
   Signature algorithm name: SHA1withRSA
   Version: 3

Copy the SHA1 fingerprint, which is highlighted in the example above.

Next, create credentials appropriate to your project in the Google Developers Console:

  1. Go to the Google Developers Console.
  2. Select a project, or create a new one.
  3. In the sidebar on the left, expand APIs & auth. Next, click APIs. Select the Enabled APIs link in the API section to see a list of all your enabled APIs. Make sure that the API is on the list of enabled APIs. If you have not enabled it, select the API from the list of APIs, then select the Enable API button for the API.
  4. In the sidebar on the left, select Credentials.
  5. Select one of the following options:

    • If your application needs to submit authorized requests:

      1. Under OAuth, click Create new Client ID.
      2. Select Installed application and Android.
      3. In the Package name field, enter your Android app's package name.
      4. Paste the SHA1 fingerprint into the form where requested.
      5. Click Create Client ID.
    • If your application only needs to make API calls that do not require authorization:

      1. Under Public API access, click Create new Key.
      2. Select Android key.
      3. Paste the SHA1 fingerprint into the form where requested.
      4. After the fingerprint, type a semicolon and then enter your Android app's package name.
      5. Click Create.

For more details, see the Android Developer Documentation.

Apple iOS

If your application accesses APIs directly from iOS, you will need the application's Bundle ID and (optionally) its Apple App Store ID:

  • The application's Bundle ID is the bundle identifier as listed in the app's .plist file. For example: com.example.myapp.
  • The application's App Store ID is in the app's iTunes URL so long as the app was published in the Apple iTunes App Store. For example, in the app URL http://itunes.apple.com/us/app/google+/id447119634, the App Store ID is 447119634.

After creating your iOS credentials in the Google Developers Console and obtaining a Client ID, you use the Installed Application OAuth 2.0 flow to communicate with Google APIs.

API keys

If your client application does not use OAuth 2.0, then it must include an API key when it calls an API that's enabled within a Developers Console project. The application passes this key into all API requests as a key=API_key parameter.

To create your application's API key, do the following:

  1. Go to the Google Developers Console.
  2. Select a project, or create a new one.
  3. In the sidebar on the left, expand APIs & auth. Next, click APIs. Select the Enabled APIs link in the API section to see a list of all your enabled APIs. Make sure that the API is on the list of enabled APIs. If you have not enabled it, select the API from the list of APIs, then select the Enable API button for the API.
  4. In the sidebar on the left, select Credentials.
  5. This API supports two types of credentials. Create whichever credentials are appropriate for your project:
    • OAuth: Your application must send an OAuth 2.0 token with any request that accesses private user data. Your application sends a client ID and, possibly, a client secret to obtain a token. You can generate OAuth 2.0 credentials for web applications, service accounts, or installed applications.

      To create an OAuth 2.0 token, click Create new Client ID, provide the required information where requested, and click Create Client ID.

    • Public API access: A request that does not provide an OAuth 2.0 token must send an API key. The key identifies your project and provides API access, quota, and reports.

      To create an API key, click Create new Key and select the appropriate key type. Enter the additional information required for that key type and click Create.

Best practices for securely using API keys

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 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.
Restrict your API keys to be used by only the IP addresses, referrer URLs, and mobile apps that need them
By restricting the IP addresses, referrer URLs, and mobile apps that can use each key, you can reduce the impact of a compromised API key. You can specify the hosts and apps that can use each key from the Google Developers Console by opening the Credentials page and then either creating a new API key with the settings you want, or editing the settings of an API key.
Delete unneeded API keys
To minimize your exposure to attack, delete any API keys that you no longer need.
Regenerate your API keys periodically
You can regenerate API keys from the Google Developers Console by opening the Credentials page and 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.

Monitoring, filtering, and capping usage

To see traffic reports and billing information for a project or API, enable billing first.

To enable billing for your project, do the following:

  1. Go to the Google Developers Console.
  2. Select a project, or create a new one.
  3. In the sidebar on the left, select Billing & Settings.
  4. In the Billing section, click Enable billing.
  5. If you do not have a billing account, create one.
  6. Select your location, fill out the form, and click Submit and enable billing.

After billing is enabled, a summary of the traffic associated with your project is available on your project's overview page. To return to your overview page, expand the top section in the sidebar on the left (titled with your project name) and click Overview.

To view more details, click Details in the top right corner of the overview page next to Estimated charges this month.

To view traffic summaries for a specific API, do the following:

  1. In the sidebar on the left, expand APIs & auth.
  2. Click the name of the API.
  3. Near the top of the page, click Quota or Usage.

Filtering usage

You can choose to handle requests only from specific hosts or IP addresses. However, this filtering applies only to requests that include an API key, not to requests that include only an OAuth 2.0 token.

To view or change usage limits for your project, or to request an increase to your quota, do the following:

  1. Go to the Google Developers Console.
  2. Select a project, or create a new one.
  3. In the sidebar on the left, expand APIs & auth.
  4. Click APIs to go to the API section.

If you have enabled billing for your project, you can see the quota percentage for each API. You can view and change quotas from the API section's API Library and Enabled APIs links. Selecting an API from the API Library list or from the Enabled APIs page takes you to a page with overview, usage, and quota links for that API. Choosing Quota lets you view and change quota-related settings. Choosing Usage provides you with usage statistics as well as response code and method information.

Capping usage

You can explicitly cap requests in two ways: requests per second per user, and requests per day.

Requests per second per user

You can limit the number of requests per second per user for an API in order to prevent individual users from using up your API quota. Each API includes a default per-user limit, but you can modify that value.

Individual users are identified either by their IP address or by a unique string; if you're creating a server-side application (where the calling code is hosted on a server that you own) that makes requests on behalf of users, your requests must include the userIp parameter or the quotaUser parameter, as described below.

Note that although per-user limits are specified in queries per second, we permit short-term usage spikes. Therefore, you should set your limits based on sustained average traffic levels. If anyone tries to use an API in excess of these settings, the requests will trigger a "limit exceeded" error.

There are two ways to identify a user:

  • To identify a user by IP address, include the userIp=x.x.x.x parameter in your requests, where x.x.x.x is the IP address of the user for whom the server-side application is making the call.
  • If your application doesn't know the user's IP address (for example, if your application runs cron jobs on App Engine on a user's behalf), then use the quotaUser=userID parameter. You can choose any arbitrary string under forty characters long that uniquely identifies a user. If you provide both parameters, quotaUser overrides userIp.

These parameters are used for capping requests per user per second; you can't use them for whitelisting. If you don't send the userIp or quotaUser parameters, then all calls are listed as coming directly from the server-side machine itself, in which case calls can't be capped by user.

When sending the user's IP address or other identifier, please be sure that you comply with any local laws, including any laws relating to the disclosure of any personal information you send with each request.

Requests per day (available only when billing is enabled)

You can set daily limits to all requests to any billable API. Most APIs set a default daily limit, but you can change that limit, up to a maximum specified by Google. This will cap requests from all users.

Note: You can set daily billable limits only on billable APIs. If your project doesn't use any billable APIs, you can't set daily limits.

Billing

Some APIs in the Google Developers Console charge for usage, and you need to enable billing before you can start using these APIs. Enabling billing for the APIs that your projects use also has other advantages:

  • Some APIs allow free usage up to a courtesy usage limit, and in some cases this free limit is increased when you enable billing. For example, when you enable billing for Google App Engine, your daily maximum and rate limits are raised for most resources. For some App Engine resources such as incoming bandwidth, the free quota is also raised.
  • For some APIs, more services are available after you enable billing. For example, when you enable billing for BigQuery, you can create your own tables; if you do not enable billing, you are limited to existing datasets.

Billing is enabled at the project level, not the API level. If you enable billing for a project, then every activated, billable API in that project is billed, based on the project's usage. All usage in a project is billed using the payment method that you specify, and you can change to a different method at any time. You cannot selectively enable billing for some active APIs but not others: when you enable billing for a project, it applies to all the APIs that you have activated within that project.

You are billed only for usage of activated, billable APIs. For complete billing and usage rules, see Google Cloud Platform Pricing Details and your API's documentation.

To enable billing for your project, do the following:

  1. Go to the Google Developers Console.
  2. Select a project, or create a new one.
  3. In the sidebar on the left, select Billing & Settings.
  4. In the Billing section, click Enable billing.
  5. If you do not have a billing account, create one.
  6. Select your location, fill out the form, and click Submit and enable billing.

After you enable billing, any requests to billable APIs beyond their free courtesy usage limits are billed, subject to the billing terms of each API. Google charges you at the beginning of each month using your specified payment method.

Back to top