This page describes the Google APIs Console, which is being replaced by the new Google Developers Console. See the Google Developers Console Help page for the new help documentation.

The Google APIs Console is a web interface for managing and viewing traffic data, authentication, and billing information for the Google APIs that are used by your project. In the APIs Console, a project is a named collection of information about your application: auth information, team members' email addresses, the Google APIs that your application uses, and so on. You can create your own projects, or be added as a viewer or editor to existing projects created by other developers. At the top of the Console is a dropdown list that shows the projects that you have access to, as well as commands for creating and managing projects. Read more about creating a new project.

The Console lets you see and manage the following project information:

Activated APIs
Activate one or more APIs to enable traffic monitoring, filtering, and billing, and API-specific pages for your project. Read more about activating APIs here.
Traffic information
The Console reports traffic information for each activated API. Additionally, you can cap or filter usage by API. Read more about traffic reporting and request filtering here.
Billing information
After you enable billing, your activated APIs are allowed to exceed the courtesy usage limit. Usage fees are billed to you using the payment method that you specify. Read more about billing here.
Project keys
Each project is identified by either an API key or an OAuth 2.0 token. Use this key/token in your API requests to identify the project, in order to record usage data, enforce your filtering restrictions, and bill usage to the proper project. You can use the Console to generate or revoke API keys or OAuth 2.0 certificates to use in your application. Read more about keys here.
Team members
You can specify additional members with read, write, or ownership access to this project's Console page. Read more about team members here.


  1. Managing projects
    1. Creating a project
    2. Deleting a project
    3. Managing project members
    4. Activating or deactivating APIs
  2. Keys, access, security, and identity
    1. Generating, editing, or revoking OAuth 2.0 credentials
    2. Generating, using, or revoking your API key
  3. Monitoring, filtering, and capping usage
    1. Viewing usage
    2. Downloading historical usage data
    3. Filtering usage
    4. Capping usage
  1. Billing
    1. Enabling billing
    2. Disabling billing
    3. Updating billing information
    4. Capping your bills
    5. See your billing history and current statement
  2. API-specific Console pages

Managing Projects

A project consists of a set of users, a set of APIs, and billing, authentication, and monitoring settings for those APIs. All API requests must identify themselves as associated with a single project by use of an API key or OAuth 2.0 credentials.

Here are the settings and information available for each project:

Team members
Specify who can see or edit the project settings and data.
Activated APIs
Activate one or more APIs for each project. Activating an API means compiling traffic data for that API in that project, and enabling usage filtering and capping for the API. Activating an API in a project also adds any API-specific pages to that project's Console.
API key and/or OAuth 2.0 credentials
You can either generate an API key for this project, or optionally generate OAuth 2.0 credentials to use with APIs activated for this project. The key or credentials identify API calls as being associated with this project.
Traffic data
See traffic data broken down by API, and filter or cap requests by user, API or other values.
To use billable APIs, enable billing and set up a billing profile.


  1. Creating a project
  2. Finding your project number
  3. Setting a project ID
  4. Deleting a project
  5. Managing project members
  6. Activating or deactivating APIs

Creating a project

You can use one 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, 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 in the Console might make sense. You can create as many projects as you need, but please remember that you cannot use multiple projects to try to exceed the limits for API usage by your application.

Here are the general steps for creating a new project:

  1. Create a new project - The dropdown at the top of the page lets you browse, open existing projects, or create a new project. Choose a useful name for the project. Note that the project name is only used in the Console; it is not the same as the project name component used by some Google APIs.
  2. Activate APIs - Go to the Services pane to activate any APIs that your project will use. Activating an API means that it will shares the same key and billing information as other active APIs in the project, and also adds any API-specific pages to the Console. You can activate the same API in multiple projects with settings unique to each project.
  3. Set up keys and/or OAuth 2.0 credentials - Create the API keys and/or OAuth 2.0 credentials that your client applications will use to identify themselves in API calls.
  4. Enable billing - If you need to use more than the advertised courtesy usage limit of your activated APIs, you must enable billing for your project. Exceeding a free usage limit without enabling billing will cause your API calls to fail.
  5. Add team members - Add members who can read or change project settings.

Finding your project number

There are two ways to identify your project: the "project number" and the "project ID."

Every project has a project number, assigned by the Console. To find your project number:

  1. Visit the APIs Console.
  2. Select your project from the project menu.
  3. Examine the URL of the project page, in your browser's URL bar. Look for the word "project:" in that URL. After that word, there's a number, about twelve digits long. That number is your project number.

For example, if the URL is:


Then the project number is 12345679012.

Setting a project ID

There are two ways to identify your project: the "project number" and the "project ID."

The project ID is an optional identifier that you can assign to your own project. It's used by services like Google Cloud SQL when they need access to your project's resources.

You don't need to assign your project an ID until you enable one of the services that requires an ID.

Note: A project ID cannot be changed, so choose an ID that you'll be comfortable using for the lifetime of the project.

To register an ID if your project doesn't already have one:

  1. Open the registration dialog box. There are two options for doing this:
    • Enable a service in the Services pane that requires a project ID. (There's no way to tell ahead of time whether a given service requires a project ID; if you enable a service and it requires an ID, then the dialog appears.)
    • In the Overview pane, find the Project ID line, and click the Register link.
  2. Enter a new project ID into the text box. For details on what characters are allowed in the ID, see the description below the text box.
  3. A project ID must be unique within your domain. To make sure the ID you've entered isn't already in use, click the "Check availability" button. If an error message appears saying that the ID isn't available, then pick a new one.
  4. When you've entered an available ID, click the "Choose this ID" button.

To find your project ID later, do the following:

  1. Visit the APIs Console.
  2. Select your project from the project menu.
  3. Select the Overview pane.
  4. Look at the Project ID line.

Deleting a project

Deleting a project from the Console releases all resources used within the project itself. Please note that in order to delete a project, you must first disable billing on the project. Additionally, please note that the time it takes to delete a project may vary based on the number or kind of services in use within the project.

The deletion of the projects that have billing set up will not complete until the current billing cycle ends. Typically, this means until you receive the next bill for the project being removed at the end of the month, and your account has been successfully charged. Also, the removal of some heavyweight services may take a while to complete.

Should you change our mind, you have seven days to undelete the project, counting from the time you deleted it. Undeleting will return the project to its state prior to deletion.

Since only a project's owner can delete (and undelete) a project, only such persons assigned that kind of role on a project will see the "Delete..." and "Undelete..." options in the project menu within the Console.

Once a project has been marked for deletion, Google emails all project members, informing them of the pending project deletion. At that point, a project owner can then choose to undelete the project, if necessary.

Projects marked for deletion are removed from the list of active projects; nobody except the project's owner can open and view the project within the Console. However, the project will appear in the project owner's "Undelete..." window for as log as it's possible to undelete the project.

The removal flow is as follows:

  1. A project owner starts project deletion by selecting the "Delete..." option from the project drop-down menu.
  2. All project members are sent an email notification that their project will be removed. The email contains the undelete deadline (the time until which undelete is possible), as well as the undelete URL, which can be used by the owners to undelete.
  3. The delete flow will then be paused for 7 days. During this time, the project owners may visit the undelete link. The project being deleted will be available for undeletion to the project owners. You can find the project to be deleted through the window that opens once the owner selects the "Undelete..." option in the project menu.
  4. Please note: during the delete flow, all billable APIs within the to-be-deleted project will not function because billing has been turned off for this particular project. Non-billable APIs will continue to function. Lastly, the project appears invisible for changes to anyone but project owner(s) unless said owner(s) undelete the project, thereby making the project again visible.
  5. If none of the owners choose to undelete the project in the 7 days after the removal, the project will become inaccessible. The billing on the project (if any) will be stopped. It may take up to 1 month for the billing to be fully turned off for your project.
  6. If none of the project owners undeletes the project within seven days of deleting the project, the project then becomes permanently inaccessible. Please note that it may take up to one month for the final invoice for your project to become available.
  7. Thereafter, the services are being shut down, and the project and its resources data are no longer available for use.

Managing project members

Add, edit, or remove project team members using the Team pane. Team members are identified by Google ID. Google IDs must be for individual users; the Console does not yet support group membership. The following roles are available to team members:

Can make any changes to the project. If you are an owner you can delete other owners.
Can make any changes in the project except managing team members.
Can read all the project settings and information, but not change them.

Activating or Deactivating APIs

A list of available APIs appears in the Services pane. Activating an API associates the current project key with that API and adds monitoring pages for that API, enables billing for that API (based on the project key), and adds any custom Console panes for that API. You must activate any API that you are using for production code, and use the appropriate API key/OAuth 2.0 token to identify requests associated with that project.

Some APIs are in preview mode, meaning that they require special sign-up and whitelisting before you can try them out. If you'd like to test one of these APIs, click the link on the service list.

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 active APIs.

You can activate the same API for different projects, and have different monitoring and billing information associated with that project.

Note: When activating the Google Places API, you will be asked to supply additional information about the project, which may include the name and website URL of the organization on behalf of whom you are developing, and the name of the application you are developing. This information, which will not be shared outside of Google, is used to help Google understand how the API is being used and as secondary contact details should we wish to contact you regarding your use of the service. You can update this information at any time on the Overview page for your project.

Back to top

Keys, access, security, and identity

The APIs represented in the Google APIs Console require that requests include a unique project identifier. This enables the Console to tie a request to a specific project in order to monitor traffic, enforce quotas, and handle billing. Google supports two separate mechanisms to create a unique project identifier: OAuth 2.0 client IDs and API keys.

  • An OAuth 2.0 client ID can generate an access token for an application that uses the OAuth 2.0 protocol to call Google APIs. The token contains an identifier that uniquely identifies your application, and allows the Console to properly attribute corresponding API traffic, quotas, and billing data to the Console project that the API is enabled within.
  • An API key is a unique key that you generate using the Console. When your application needs to call an API that's enabled in this project, the application passes this key into all API requests as a key=API_key parameter. Use of this key does not require any user action or consent, does not grant access to any account information, and is not used for authorization.

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

Note: You must use either an OAuth 2.0 access token or an API key for all applications. Not all APIs require authorized calls. See your API documentation to learn whether authorization is required for specific calls.


  1. OAuth 2.0 Client IDs
  2. API Keys

OAuth 2.0 client IDs

In order to use OAuth 2.0 in your application, you must first generate an OAuth 2.0 client ID by specifying some branding information for your project. Your application uses this client ID when requesting an OAuth 2.0 access token. Google uses the branding information to render the consent page that requests authorization from users. You can generate, edit, or revoke OAuth 2.0 client IDs and branding information using the API Access pane.

When you create a client ID, you must specify the type of application the client ID is for. You can currently choose between a Web application and an Installed application, or you can choose to create a client ID for a Service account. Each Console project supports up to twenty OAuth 2.0 client IDs at any one time, so, your project can define an application with multiple components. Google strongly recommends not sharing OAuth 2.0 client IDs between Console projects. For more information about how to implement OAuth 2.0 in your application, see Google's OAuth 2.0 documentation.

Branding information

Specify branding information about your application in the Console's API Access pane. If your project does not yet have an OAuth 2.0 client ID, then you can specify branding information by clicking the "Create an OAuth 2.0 client ID" button, as shown below:

Button to create an OAuth 2.0 client ID

The next window that appears prompts you to enter your application's name (as it would appear to your end customer), and to specify a logo for your application. The only required item is the application's name; however, Google recommends specifying both a name and a logo, if possible.

Form to enter branding information

The values you specify here are shown to your application's users via the OAuth 2.0 consent page. For more information, see the OAuth 2.0 documentation.

When you're done entering branding information, click Next to choose an application type.

Note: You can change the branding information later by clicking the "Edit branding information" button in the Console's API Access pane, as shown below:

API Access pane of APIs Console

Choosing an application type

The next step in creating a client ID is indicating what type of application you're creating.

Select application type

Google supports the creation of the following types of OAuth 2.0 client IDs:

On the "Client ID Settings" screen (as shown above), select the type that corresponds to your application. When you're done, click the "Create client ID" button to create an ID.

The following sections describe the three types of applications.

Web applications

If your application is to be used in a web browser, then select "Web application." With this type of client ID, you can use any of three OAuth 2.0 flows, as described in Google's OAuth 2.0 Login, Web Server, and Client-Side documentation.

When you select this type of client ID, you must specify the site or hostname. In the example shown above, the OAuth 2.0 authorization response will be sent to https://www.example.com/oauth2callback. To enter multiple hostnames, click the "more options" link. You may also change these settings later, as needed.

If you are using HTML5 postmessage() as a transport for returning a token, then specify the authorized Javascript origin(s).

Service accounts

If your application employs server-to-server interactions, such as those between a web application and Google Cloud Storage, then select "Service account." With this type of client ID, you can use the OAuth 2.0 Service Accounts flow, as described in Google's OAuth 2.0 Service Accounts documentation.

When you click the "Create client ID" button after selecting "Service account," the next window indicates that Google has generated a public-private key pair for you, as shown below:

Public-private key pair generated

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 the "Download private key" button, 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 will need to provide the password notasecret. Please 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 or rollover credentials without application downtime. Note, however, that you cannot delete a key pair if it is the only one created for that service account.

In the following image, you can see both the client ID and email address:

Service account information

Use the client ID when making the OAuth 2.0 access token request (see Google's OAuth 2.0 Service Account documentation). Use the email address when granting the service account access to supported Google APIs (see, for example, the Google Cloud Storage documentation).

Reminder: When you use a Service account, you are subject to the Terms of Service for each product both as an end user and as a developer.

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, Google Android, and so on), then select "Installed applications" and a specific application type. With this type of client ID, you can use either of two OAuth 2.0 flows, as described in Google's OAuth 2.0 Installed Applications and Devices documentation.

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 Installed Application > Chrome Application and enter your Chrome app or extension's Application ID. For more information about these APIs, see the Google Chrome Identity API documentation.

Android client IDs

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

On Android, to authenticate and communicate with (for example) the Google+ APIs, register your digitally signed .apk file's public certificate in the Google APIs Console, using the following procedure:

  1. On the "Client ID Settings" screen, select "Installed application" and "Android" as the application type.

    GUI to create a client ID for Android

  2. In the "Package name" field, enter your Android application's package name.
  3. 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.

  4. 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
  5. Paste the SHA-1 fingerprint into the "Signing certificate fingerprint" field and click the "Create client ID" button.

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

For more details, see the Android Developer Documentation.

Apple iOS client IDs

On Apple iOS, to authenticate and communicate with (for example) the Google+ APIs, register your app's Bundle ID and the Apple App Store ID (optional) using the following procedure:

  1. On the "Client ID Settings" screen, select "Installed application" and "iOS" as the application type.

    GUI to create a client ID for iOS

  2. In the "Bundle ID" field, enter the bundle identifier as listed in your application's .plist file, such as com.example.myapp.
  3. In the "App Store ID" field, enter the App Store ID if the app was published in the Apple iTunes App Store.

Note: You may also 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've registered your app and have been assigned a client ID, you may follow the Installed Application OAuth 2.0 flow to communicate with the Google+ API.

API keys

If your client applications do not use OAuth 2.0, then you must include an API key with all API requests. You need one API key per project. Create an API key in the API Access pane, in the Simple API Access section, as shown below:

Buttons to create new API keys

The Console enables you to create server, browser, Android and iOS API Keys. Once you've created a key, you restrict where it can be used. The available restrictions depend upon the type of key.

  • Server keys can be restricted based on your servers' source IP address(es).
  • Browser keys can be restricted based on HTTP referrer.
  • Android keys can be restricted based on the package name and certificate SHA-1 fingerprint.
  • iOS keys can be restricted based on the bundle identifier.

Note: Android and iOS keys are only supported by some APIs, such as the Google Maps Android API or the Google Maps SDK for iOS.

Your project can therefore have server-side components in conjunction with browser and/or mobile components, without fear of compromising your server(s) if a browser key or mobile key is compromised.

For server and browser keys, add the key=your_key parameter in all requests to use the key, replacing your_key with the value shown in the "API key" section of the Console. For Android and iOS keys, add the value shown in the "API key" section of the Console to your application (for example, as an attribute in your AndroidManifest.xml).

If you believe that your key has been compromised—for instance, if you notice suspicious activity in your Console traffic reports—then Google recommends generating a new key by clicking the "Generate new key" button to the right of the key. Upon doing this, you can decide whether or not to allow up to 24 hours to phase out your old key, during which time both keys are active. Using a phased deactivation gives you time to fully deploy your new key. If, instead, you want to invalidate the old key immediately, then click the "Delete key" button to the right of the key.

Back to top

Monitoring, Filtering, and Capping Usage

The Console provides monitoring panes that let you view your daily traffic history. It also provides tools to filter or cap your requests by user, request URL, or daily limits.

Each API has a per-project usage limit. If your application tries to use more than its limit, additional requests will fail. You can see API usage limits on the Quotas pane.

If you need additional quota, enable billing (for billable APIs) or click the "Request more" link.


  1. Viewing usage
  2. Downloading historical usage data
  3. Filtering usage
    1. By host
    2. By IP address
    3. With OAuth keys
  4. Capping usage
    1. By user
    2. By daily limits

Viewing usage

You can view your usage by API on the Reports pane.

Downloading historical usage data

You can download historical usage data for your API by clicking on the "Download Historical Quota Usage Data" link for that particular API in the Reports pane.

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 token. For more information, see Whitelisting and OAuth tokens.

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

Whitelisting by Host (Browser-embedded scripts)

Limiting requests by host is used to accept calls from in-browser scripts hosted on specific web pages or sites.

To whitelist by host:

  1. On the Quotas pane, click Configure traffic filters... and select "Browser-embedded scripts".
  2. Add one or more URL patterns to the traffic filters dialog box; requests from non-matching URLs will be rejected. Wildcards are allowed at the beginning and end of each pattern. Here are some example patterns:
    URL Pattern Description
    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.

To whitelist by IP address, on the Quotas pane, click Configure traffic filters... and add the IP or CIDR addresses of the machines hosting the server-side application: for example, or

Whitelisting and OAuth tokens

Filtering is tied to your API key. If you send a request with an OAuth token but no API key, then filtering isn't applied to that request.

Thus, there is currently no way to enable filtering for requests that require an OAuth token.

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.

Per-user limits are visible for each API on the Quotas pane, next to the API. To modify this value, click the Set per-user limits button and adjust the rate as desired.

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). To change the daily limit, click Set billable limits on the Quotas pane and set appropriate values in the dialog box. This will cap requests from all users.

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.

Back to top


Some APIs in the Console charge for usage. The API list on the Services pane summarizes the courtesy usage limits for each API; to use the API beyond that free quota, you must enable billing for your project.

Billing is enabled at the project level, not the API level. If you enable billing for a given project, then all activated, billable APIs in that project will be billed based on your project's usage. All usage in a project is billed using the payment method that you specify; you can change to a different method at any time.

You will be billed only for usage of activated, billable APIs. See your API's documentation to learn its complete billing and usage rules.

APIs that are billable have a "Pricing" link in the Services pane. If your project doesn't use any billable APIs, then you can't enable billing. To request a higher usage quota for a non-billable API, visit the Quotas pane and click the "Request more" link.


  1. Enabling billing
  2. Disabling billing
  3. Updating billing information
  4. Capping your bills
  5. See your billing history and current statement

Enabling billing

If your project uses any billable APIs, then you can enable billing in the Billing pane of the Console. (That pane doesn't appear unless your project uses a billable API.) When you click to enable billing, you're prompted to set up a billing profile, including specifying a payment method.

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. To view your charges, see the Billing pane.

Disabling billing

You can disable billing for a project at any time on the Billing pane. When you cancel billing, your project returns to an "unbilled" state, and all activated APIs will be restricted to the courtesy usage limit.

After you cancel billing, your specified payment method will be charged at the end of the normal billing cycle. There is a small lag (about five days) after you disable billing during which you may see additional usage fees added to your bill, since API usage takes a few days to properly record and calculate. The billing tab of the Console will say "Billing is being cancelled" until your last bill is paid.

Updating billing information

To change how your project is billed, go to the Billing pane and click Settings. You can change the payment method for your project without interrupting service; for example, any team member with write access on the project can accept or modify their billing responsibility for a project.

As soon as you change your billing information, any existing balance is transferred to the new account, and all new charges will be sent to the new account.

Capping your bills

Most billable APIs have a small, free "courtesy limit" usage quota, shown on the Services pane. After you enable billing for your project, your usage caps are increased to the billable limits, and any requests to billable APIs beyond their daily courtesy usage limits are billed (subject to the billing terms of each API). To help limit your bills, you can arbitrarily set the following values for each API:

  • Per-user limits
  • Daily limits
  • Traffic filters limiting whom you will accept requests from

For details, see Monitoring, Filtering, and Capping Usage.

See your billing history and current statement

To see your billing history and your current statement, visit the Billing pane.

Back to top

API-Specific Console Pages

The Console also includes pages that are specific to individual APIs. These API-specific pages are listed on the left of the page, at the bottom.

Google Storage for Developers

Google Storage for Developers offers the following two pages on the console:

Storage Access

The Storage Access pane contains information about your Google Storage account such as your project ID and Google Storage IDs.

Legacy Access

The Legacy Access pane contains your Google Storage developer keys. This page is only available if you enable legacy access in the Storage Access pane.

Send feedback about...

APIs Console Help