When you create and register a new project in the Google APIs Console, you are given a unique client ID to identify each application under that project. Note that all the applications under a single project share any per project limits.
General Analytics API quotas
These apply to both the Analytics APIs, i.e., Management API and Core Reporting API:
- 50,000 requests per project per day
- 10 queries per second (QPS) per IP
Quotas specific to Core Reporting API
- 10,000 requests per profile per day
- 10 concurrent requests per profile
For unregistered applications, we provide a very low grace quota to accommodate a small amount of testing. If quota is exceeded, Google Analytics API returns an error for additional requests: HTTP status code 403 Forbidden and a message indicating that the specific account has insufficient quota to proceed.
Authentication and authorization
Given the security implications of getting the implementation correct, Google strongly encourage developers to use OAuth 2.0 libraries when interacting with Google’s OAuth 2.0 endpoints. At a high level, using OAuth 2.0 to access a Google API consists of four steps:
- Register Application
- Obtain an Access Token from the Google Authorization Server
- Send Access Token to an API
- Refresh the Access Token (optional)
The OAuth 2.0 playground is a fantastic tool that allows you to go through the entire authorization flow through a web interface. The tool also displays all the HTTP request headers required for making an authorized query. If you can’t get authorization to work in your own application, you should try to get it working through the OAuth 2.0 playground. Then you can compare the HTTP headers and request from the playground to what your application is sending Google Analytics.
All applications that access a Google API must be registered through the APIs Console. The result of this registration process is a set of values that are known to both Google and your application . The set of values generated varies based on what type of application you are building.
Obtain an Access Token from the Google Authorization Server
Before your application can access a Google API, it must obtain an access token that grants access to that API. A single access token may grant varying degrees of access to multiple APIs. The set of resources and operations permitted by an access token is controlled during the access token request via a variable parameter called scope. Several scopes may be included in a request. There are several ways to make this request, and they vary based on the type of application you are building.
The request requires the user to login to Google. After logging in, the user will see the permissions requested by the application and is asked if they are willing to grant your application those permissions. This process is called user consent. If the user grants permission to your application, your application will be sent an access token or an authorization code (which is used to obtain an access token).
Send Access Token to an API
After an application has obtained an access token, it may send the access token in a request to a Google API. Access tokens are valid only for the set of operations and resources described in the token request. For example, if an access token is issued for the Google+ API, it will not grant access to the Google Contacts API. It may, however, be sent to the Google+ API multiple times for similar operations. Access tokens are sent to a Google API in the HTTP Authorization header, or as a query string parameter (if HTTP header operations are not available).
Refresh the Access Token (optional)
Access tokens have a limited lifetime and, in some cases, an application needs access to a Google API beyond the lifetime of a single access token. When this is the case, your application can obtain what is called a refresh token. A refresh token allows your application to obtain new access tokens.
User login is clearly an essential part of most Google API access, but Google’s authentication system can be used by your application as a stand-alone component. In other words, you can outsource user authentication and profile acquisition to Google.
The login sequence starts by redirecting the browser (popup, or full-page if needed) to a Google URL with a set of query string parameters. Google handles selecting the correct session, accepting and validating the user credentials and one-time-passwords, obtaining consent to release basic profile information, as well as minting and returning an OAuth access token to your application.
The result of the user authentication sequence is an OAuth 2.0 access token.
Web Server Applications
The Google OAuth 2.0 Authorization Server supports web server applications. This sequence begins by redirecting a browser (popup, or full-page if needed) to a Google URL with a set of query parameters that indicate the type of Google API access the application requires. Like other scenarios, Google handles the user authentication, session selection and consent, but the result of the sequence is an authorization code. After receiving the authorization code, the application can exchange the code for an access token and a refresh token. For more information, see the Web Server documentation.
Authenticating Users in Mobile Apps
Many web applications have companion mobile applications, such as native Android and iOS apps. These native applications typically ask the user for their email address and password to authenticate them. This method of authentication will not work when the web application has a complex login system which uses technologies like OpenID or SAML for federated authentication. In this guide, we’ll describe an alternative technique to enable mobile applications to work for all users, regardless of how they are authenticated. For more information, see the Authenticating Users in Mobile Apps documentation.