This page is only for customers with a previous Maps APIs for Work or Maps API for Business license. This page is not applicable to customers with the new Google Maps Platform Premium Plan, which became available in January 2016.
Client IDs
Authentication to the Maps JavaScript API for Google Maps APIs for Work customers requires a unique client ID in combination with URL registration.
Get a client ID
To access the special features of Google Maps APIs for Work, you must
provide a client ID when accessing any of the API libraries or services. When
registering for Google Maps APIs for Work, you will receive this client ID
from Google Cloud Support Portal. All client IDs begin with a gme-
prefix.
This client ID is not a key. It will only work from URLs which you authorize, so you don't need to worry about keeping it secret.
Specify a client ID when loading the API
Specify your client ID as the value of a client
parameter when
loading the Maps JavaScript API:
<script async defer
src="https://maps.googleapis.com/maps/api/js?client=YOUR_CLIENT_ID
&v=quarterly&callback=initMap"></script>
As shown in the above example, you must specify the
release version (also
referred to as the feature-stable version) or an earlier
version, by appending a v=quarterly
parameter. Applications
that use the weekly channel are not covered under the
Google Maps APIs for Work SLA.
Register your 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:
- Log in to the Google Cloud Support Portal.
- In the left-hand menu, click Maps: Manage Client ID.
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
andhttp://192.168.1.1
are valid entries. - All subdomains of a specified domain are also authorized.
- For example, if
http://example.com
is authorized, thenhttp://www.example.com
is also authorized. The reverse is not true: ifhttp://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, thenhttp://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 ashttp://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 authorizehttp://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:
http://example.com/
also authorizes
http://sub.example.com/path
.
For more information, see Troubleshooting Authorization for Google Maps APIs for Work Implementations.