Get API Key

To use the Maps JavaScript API, you must register your app project on the
Google API Console and get a Google API key which you can add to your app.

Quick guide to getting a key

Step 1: Get an API Key from the Google API Console

Click the button below, which guides you through the process of registering a project in the
Google API Console, activates the Maps JavaScript API and any related services automatically, and
generates a generic, unrestricted API key.

Tip: During development and testing, you can register a project for testing
purposes in the Google API Console and use a generic, unrestricted API key. When you are ready to
move your app or website into production, register a separate project for production, create
a browser-restricted API key, and add the key to your application.

Premium Plan customers: For production-ready apps,
you must use a browser-restricted API key that is set up in the Google Maps APIs Premium Plan
project created for you when you purchased the Premium Plan.
Alternatively, you can use a client ID in combination with URL
registration (instead of an API key).

Choosing an authentication method for your application

The section below provides a summary of the various tools and reports that are available to
Premium Plan customers, based on the method you choose to authenticate your application.

Authentication using an API key
(Note: Customers with a current Premium Plan license
may use an API key, but customers holding a
previous Maps API for Business license must use a client ID.)
By using an API key to authenticate your applications, you can:

Note: The information below on using an API key applies only to the
Google Maps APIs Premium Plan, which became available on January 6, 2016.

Have a previous
Maps APIs for Work or Maps API for Business license?
See our Maps APIs for Work
Licenses guide. To determine whether you have a previous license: In the
Google Cloud Support Portal,
click Maps: Usage Report on the left. If the ID at the top of the report
is in the following format, you have the new Premium Plan:
gme-[company] & proj-[number] ([type])
Otherwise, you have a previous license.

Authenticating your application using an API key

From the Project drop-down menu, select the project created for you when you purchased the
Premium Plan. The project name starts with
Google Maps APIs for Business or Google Maps for Work or Google Maps. Important: If you have a
previous Maps API for Business license, you must use a client
ID, not an API key.

Click Continue.

On the Credentials page, get an API key.
Note: If you have an existing unrestricted API key, or a key with browser
restrictions, you may use that key.

From the dialog displaying the API key, select Restrict key to set a
browser restriction on the API key.

In the Key restriction section, select
HTTP referrers (web sites), then follow the on-screen instructions to set
referrers.

You must specify the release version (also
referred to as the feature-stable version) or an earlier version, by appending a
v=3.32 parameter. Applications that use the experimental version are not
covered under the Google Maps APIs Premium Plan SLA.

Note:
If you were previously using an API key for authentication and are switching to
using a client ID, you must remove the key parameter before loading
the API. The API will fail to load if both a client ID and an API key are
included.

Restricting an API key

Google Maps APIs are available for web browsers, Android or iOS apps, and via HTTP web services.
APIs in any platform can use a generic (unrestricted) API key. You can optionally add a
restriction (for example, HTTP referrer) to the API key. Once restricted, a key will only work on
platforms that support that type of restriction.

Tip: Before moving your app or website to production, you should secure your API
key. Keys for the Maps JavaScript API use the
HTTP referrers (web sites) key restriction.
Learn more about keys and credentials.

To add web browser restrictions to an existing, generic API key, do the following:

On the Credentials page, from the list of API keys, select the name
of the API key to edit the details of the key.

In the Key restriction section of the page, select
HTTP referrers (web sites), follow the on-screen instructions to set
referrers, then click Save.

Note: file:// referers need a special representation to be added to the
Key restriction. The "file:/" part should be replaced with "__file_url__" before being added
to the Key restriction. For example, "file:///path/to/" should be formatted as
"__file_url__//path/to/*".
After enabling file:// referers, it is recommended you regularly check your usage,
to make sure it matches your expectations.

Registering authorized URLs

To prevent a third party from using your client ID on their own website, the
use of your client ID is restricted to a list of URLs that you specifically
authorize.

To see the URLs you have already authorized or to authorize additional
URLs:

You can add up to 100 URLs at a time. A Client ID may be associated with up
to 3000 authorized URLs. If you expect your application to host Google Maps
content from more than 3000 locations, you should switch to using API keys
instead.

The following considerations apply regarding URLs that are authorized:

The domain name or IP address does not have to be publicly
accessible.

For example, http://myintranet and
http://192.168.1.1 are valid entries.

All subdomains of a specified domain are also authorized.

For example, if http://example.com is authorized,
then http://www.example.com is also authorized. The reverse
is not true: if http://www.example.com is authorized,
http://example.com is not necessarily authorized.

All subpaths of an authorized path are also authorized.

For example, if http://example.com is authorized, then
http://example.com/foo is also authorized. In addition,
because subdomains of a specified domain are also authorized,
http://sub.example.com/bar is authorized.

Paths are case sensitive.

For example, http://www.example.com/ThisPath/ is not the
same as http://www.example.com/thispath/.

You may restrict valid URLs to those using certain ports.

For example, if http://example.com:8080/foo is specified,
that doesn't authorize http://example.com.

HTTP and HTTPS protocols are considered different URLs.

For example, if https://example.com is authorized,
http://example.com is not necessarily authorized. If you'd like
to authorize both at once, you may add a domain without using a protocol:
example.com/

All the rules above are applied to each authorization, so you should
take care to plan your authorizations carefully. For example, because
all subpaths of a specified path are authorized, and all subdomains, you
may end up authorizing pages that you didn't intend to. For example: