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 and applications
    1. Creating and deleting projects
    2. Project ID and project number
    3. Managing project members
  2. Activating or deactivating APIs
  3. Keys, access, security, and identity
  4. Setting up OAuth 2.0
    1. User consent
    2. Service accounts
    3. Installed applications
  5. API keys
  6. Monitoring, filtering, and capping usage
    1. Filtering usage
    2. Whitelisting
    3. Capping usage
  7. Billing

Managing projects and applications

A project consists of a set of applications, along with activated APIs, Google Cloud resources, and the team and billing information associated with those resources.

Credentials such as API keys are specific to an application rather than to a project. However, all applications within a given project use the same branding information (logo, email address, etc.) on their user consent screen, as described in Setting up OAuth 2.0. Applications within a project also share activated APIs, permissions, and billing information.

Creating and deleting projects

You can use one Google Developers Console project to manage all of your applications, or you can create a different project for each one. In deciding whether to create a new project for a given application, consider whether you're collaborating with a different set of people, want to track usage differently, or would set different traffic controls for each application. If so, segregating applications by project might make sense. You can create multiple projects, but remember that you cannot use multiple projects to try to exceed the limits for API usage by your application.

Creating a project and registering an application

To create a project, do the following:

Visit the Google Developers Console and select Create Project. Enter a name and a project ID, or accept the defaults, and select Create.

To register a new application, 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 APIs & auth. In the displayed list of APIs, make sure all the APIs you are using show a status of ON.
  4. In the sidebar on the left, select Registered apps.
  5. At the top of the page, select Register App.
  6. Fill out the form and select Register.

Deleting a project

Deleting a project from the Developers Console releases all resources used within the project. Only project owners can delete projects, so only project owners will see the delete (and undelete) options within the Developers Console.

To delete a project, do the following:

  1. Disable billing on the project.
  2. Mark the project for deletion in the Developers Console. At this point, Google emails all project members to inform them of the pending project deletion.
  3. If you change your mind, undelete the project. Undeleting a project is possible for seven days, counting from the time you marked the project for deletion. Undeleting returns the project to the state it was in prior to deletion.

The deletion of a project that has billing set up will not be complete until the current billing cycle ends. Typically, this means that the project will not be deleted until you receive the next bill for the project and your account is charged successfully. Also, the time it takes to delete a project might vary depending on the number or kind of services in use within the project.

Project ID and project number

There are two ways to identify your project:

  • The project ID is an identifier that you select when you create the project, and it is used only within the Developers Console. A project ID is unique and cannot be changed, so choose an ID that you'll be comfortable using for the lifetime of the project.

    To determine your project ID, visit the Developers Console. Find your project in the list on the main landing page. The project ID appears in the second column of the table.

  • The project number is assigned by the Google Developers Console.

    To determine your project number, visit the Developers Console. Select your project in the list on the main landing page. The project number appears at the top of the project's overview page.

Managing project members

If you create a project, you have owner-level permissions and can grant owner-level permissions to other project members. Those with owner-level permissions are project owners.

Only project owners can add and remove other project members and edit their permission levels. Project owners can share a project with an email address that represents a group, but every project must have at least one project member that is an individual, not a group.

To manage project members, do the following:

  1. Visit the Google Developers Console.
  2. Select a project, or create a new one.
  3. In the sidebar on the left, select Permissions.
    • To add a team member or group, select Add Member. You must provide an email address that is associated with a Google account. If the email address belongs to an individual, an invitation flow is triggered, 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.
    • To change the permission setting for a project member, 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, click the trash icon to the right of the project member's permission setting.

Activating or deactivating APIs

Activating an API associates that API with the current project and adds monitoring pages for that API, enables billing for that API, and adds any custom information to the Developers Console for that API.

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

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

  1. Go to the Google Developers Console.
  2. Select a project.
  3. In the sidebar on the left, select APIs & auth.
  4. In the displayed list of available APIs, find the one you want to activate, and set its status to ON.

You can deactivate an API for a project whenever you want, although any pending fees will still be charged to your account. 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 for the applications within that project.

Keys, 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. When you register an application in the Google Developers Console, you can generate an OAuth 2.0 client ID.

To find your application's client ID and client secret, and set a redirect URI, expand the OAuth 2.0 Client ID section.

To deactivate the client ID, delete the application from the Developers Console.

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.
  3. In the sidebar on the left, select APIs & auth. In the displayed list of APIs, make sure all the APIs you are using show a status of ON.
  4. In the sidebar on the left, select Consent screen.
  5. Fill in the form and select Save.

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

Service accounts

If your application 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. View the application:
    1. Go to the Google Developers Console.
    2. Select a project.
    3. In the sidebar on the left, select APIs & auth. In the displayed list of APIs, make sure all the APIs you are using show a status of ON.
    4. In the sidebar on the left, select Credentials.
  2. To set up a service account, select Create New Client ID. Specify that your application type is service account, and then select Create Client ID. A dialog box appears; to proceed, select Okay, got it. (If you already have a service account, you can add a new key by selecting Generate new key beneath the existing service-account credentials. A dialog box appears; to proceed, select Okay, got it.)

Your application 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.

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 register your application. 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 register an Android application in the Google Developers Console, choose Android as the platform. If your application accesses APIs directly from Android (vs. 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.

To find your SHA-1 fingerprint:

  1. In a terminal, run the following Keytool command to generate the signing certificate's SHA-1 fingerprint:
    keytool -exportcert -alias androiddebugkey -keystore path-to-debug-or-production-keystore -list -v

    Note: For Eclipse, the debug keystore is typically located at ~/.android/debug.keystore.

  2. Keytool prompts you to enter a password for the keystore. The default password for the debug keystore is android. Keytool then prints the fingerprint to the shell. For example:
    Certificate fingerprint: SHA1: DA:39:A3:EE:5E:6B:4B:0D:32:55:BF:EF:95:60:18:90:AF:D8:07:09

Note: When you're ready to publish your Android app, you must create a new OAuth 2.0 client ID in the Google Developers Console. You must then follow these steps again with your release signing certificate.

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.
  • If the app was published in the Apple iTunes App Store, you can find the App Store ID in your app's iTunes URL. For example, if your app's URL is http://itunes.apple.com/us/app/google+/id447119634, then its ID is 447119634.

After you register your application and have a client ID, you can use the Installed Application OAuth 2.0 flow to communicate with the Google+ API.

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.

Two kinds of API keys are available in the Google Developers Console:

  • Use a server key if your application is running on a server. Never share this kind of API key outside your server code. For example, never embed this key in a web page. To prevent quota theft, restrict your key so that requests are only allowed from your servers' source IP addresses.
  • Use a browser key if your application is running on a client, for example from JavaScript or any other client-side web-browser context. To prevent your browser key from being used on unauthorized sites, only allow referrals from domains that you administer.

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

  1. Go to the Google Developers Console.
  2. Select a project.
  3. In the sidebar on the left, select APIs & auth. In the displayed list of APIs, make sure all the APIs you are using show a status of ON.
  4. In the sidebar on the left, select Credentials.
  5. Find the line or lines labeled API key. If there is no API key, then create one by selecting Create New Key. For more about API keys, see the Console help.

Monitoring, filtering, and capping usage

To see traffic reports and billing information for a project, do the following:

  1. Go to the Google Developers Console.
  2. Select a project. A summary of your traffic reports appears in the page.
  3. To open more detailed reports, click Requests, Errors, or Charges.

To see traffic reports and billing information for an API, do the following:

  1. Go to the Google Developers Console.
  2. Select a project.
  3. In the sidebar on the left, select APIs & auth.
  4. Click the name of the API. In the page that opens, select Quota or Reports.

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 total limit, do the following:

  1. Go to the Google Developers Console.
  2. Select a project.
  3. In the sidebar on the left, select APIs & auth, then select an API.
  4. On the API's info page, select the Quota link near the API name.

Whitelisting

An API can be configured to filter by host or by IP address, but not by both. Any request that includes an API key but that does not match a whitelisted host pattern or IP address is rejected.

Whitelisting by host (browser-embedded scripts)

Whitelist by host if you want the API to accept calls only from in-browser scripts hosted on specific web pages or sites.

When you whitelist by host, add one or more URL patterns to the traffic filters dialog box; requests from non-matching URLs are rejected. Wildcards are allowed at the beginning and end of each pattern. Here are some example patterns:

URL Pattern Description
www.example.com
or
www.example.com/*
Matches all referrers in the domain www.example.com.
www.example.com/ Matches only referrers at www.example.com, but no subdomains.
example.com/* Matches only referrers at example.com, but no subdomains.
*.example.com Matches all referrers at all subdomains of example.com but not example.com itself.
www.example.com/test Matches only the root of the test directory of www.example.com.
www.examples.com/test/* Matches all referrers in www.examples.com/test/ and all subdomains.

Whitelisting by IP address (server-side applications)

Limiting requests by IP address is intended to allow requests only from known server-side applications. When you whitelist by IP address, add the IP or CIDR addresses of the machines hosting the server-side application: for example, 1.2.3.4 or 1.2.3.0/24.

Whitelisting and OAuth tokens

There is currently no way to enable filtering for requests that require an OAuth token, because filtering is tied to your API key. If you send a request with an OAuth token but no API key, then filtering is not applied to that request.

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 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.
  3. In the sidebar on the left, select Settings.
  4. In the Billing section, select Enable billing.
  5. Select your location and then fill in the form.

After you enable billing, any requests to billable APIs beyond their daily 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

Authentication required

You need to be signed in with Google+ to do that.

Signing you in...

Google Developers needs your permission to do that.