Author Archives: Greg Knoke

A One-Two Punch for Getting Even More out of Google Apps APIs

Editor’s Note: Guest author Steve Ziegler is a senior architect at BetterCloudArun Nagarajan

FlashPanel, a leading enterprise-grade security and management application for Google Apps, makes use of many Google Apps APIs. Each API comes with its own set of rate-limiting quotas, network traffic behavior and response conditions. The challenge we face is to provide our customers with a stable, consistent experience despite these API behavior differences. Fortunately, Google has provided two simple, yet powerful tools to greatly increase our success rate and reliability.

Controlling Throttle Rates with Guava’s RateLimiter

Google Apps APIs operate with quota rates per second or per day. As such, the FlashPanel development team’s objective is to minimize total operation time of a parallelized set of API-intensive processes while avoiding running into Google’s API quota limits. To accomplish this, we can very easily set up a thread-safe RateLimiter for a specific rate per second for each rate restricted API:

final RateLimiter driveApiRateLimiter = RateLimiter.create(QUOTA_RATE_PER_SECOND);

The Guava RateLimiter allows us to attempt to acquire a permit based on the configured rate per second, block until available, and then take it when available, allowing execution.

To use it within the context of a method, we simply reference the rate limiter before making the API call:

public Result performDriveApiCall(driveApiRateLimiter, otherParams){
driveApiRateLimiter.acquire(); // blocks according to rate
// make API call...
This provides us with a very easy solution for rate limiting parallelized calls to the same APIs.

Reducing Impact of Network Traffic Issues Through Configured Backoffs

Occasionally, we experience additional network traffic issues despite enforcing rate limits. Google suggests that API clients use an exponential backoff strategy to handle this variety of error response. Typically this category of network issue resolves itself on its own after fractions of a second, but occasionally more time is needed. All we need to do to receive a successful API response is to simply retry the call some number of times, with the interval of time between retries growing exponentially.

Again, Google has made this easy through the Google HTTP Client for Java library’s ExponentialBackOff builder. This class allows us to configure the initial retry time interval, the exponential multiplier, the maximum total time to attempt to retry, and the maximum total time between retries. For example, we could configure a retry to span five minutes, growing with a factor of two, starting at a one second interval, and growing up to a maximum of one minute between retries. An API call with this configuration would retry with the following pattern in terms of seconds between retries:

1, 2, 4, 8, 16, 32, 60, 60, 60

If after this last retry, the API call still was not successful, the failed http response is returned. The code to configure such a strategy using the ExponentialBackOff.Builder reads as follows:

ExponentialBackOff backoff = new ExponentialBackOff.Builder()

One potential “gotcha” that we’ve seen is if we accidentally slam a particular API with many simultaneous API calls. In this event, not only would each of these API calls fail, but they would also schedule their retry strategy to occur simultaneously. All subsequent retries would end up firing simultaneously, causing the API calls to continue to fail due to excess per second volumes. The ExponentialBackoff class accounts for this by including a randomization factor within our retry logic that allows us to have each simultaneous API call stagger at different intervals.

For example, using our previous backoff but now with randomization, one API call may retry with these intervals:

1.04, 1.9, 4.23, 7.8, etc.

While a second API call would retry with something like these intervals:

.98, 2.04, 4.1, 8.15, etc.

With this randomization, we avoid API call sequencing collision, mitigating our chances of encountering quota related errors. To simply add this type of randomization, we append to our builder:


Once we have our exponential backoff strategy configured, the Google HTTP Client for Java library allows us to instantiate and assign an HttpBackOffUnsuccessfulResponseHandler to an HttpRequest as part of the request’s initialization:

private HttpBackOffUnsuccessfulResponseHandler handler = new HttpBackOffUnsuccessfulResponseHandler(backoff);

public void initialize(HttpRequest request){

Final Thoughts

By restricting our API calls using Google Guava’s easy-to-use RateLimiter, and by employing an exponential backoff strategy using the Google HTTP Client for Java library’s ExponentialBackOff, we are able to significantly reduce the amount of network traffic errors received by our Google Apps API calls, improving FlashPanel’s reliability and the overall user experience.

Steve is Senior Architect at BetterCloud, the makers of FlashPanel, the number one security and management application for Google Apps. Follow BetterCloud on Google+ at

Posted by Greg Knoke, Googler

Get coding fast with Code School and the Google Drive API

The most challenging part of learning anything new is often simply getting started. Unfortunately, when it comes to programming, the first few minutes (or more!) are often occupied with cumbersome details such as setting up an environment, which results in very little time spent actually writing code. We were certain there must be a better way.

Code School has been doing exciting things with learning to program online. This is why we decided to team up with them to create a way for developers to learn to use the Google Drive API, with no setup required. In the Discover Drive course, you can learn at your own pace from your web browser. You’ll spend less time fussing with coding environments and more time writing code.

To find out what the course is all about, go check it out at Code School. Happy coding!

Cross-posted on the Google Developers Blog.

Greg Knoke Google+

Greg Knoke is a technical writer in the Google Drive Developer Relations Team. Prior to joining Google, he worked as a scientist developing image and signal processing algorithms. His current interests include new technologies, content management, information architecture, cooking, music, and photography.

Building an Enterprise File Server on Google Drive

Editor's note: This is a guest post by Thomas Gerber. Thomas is the CTO of Altirnao, the developer of the AODocs document management app on the Google Apps Marketplace. Thomas tells the story of his application and provides some tips for developers considering integrating with Google Apps and launching on the Marketplace. — Arun Nagarajan

Google Drive is increasingly popular in the enterprise, and many organizations would like to leverage it as a replacement for their existing on-premises file servers. Moving physical file servers to Drive provides many benefits, such as reliability, cost-effectiveness and the ability to access the files from anywhere and any device. However, the storage structure of Google Drive, where files are owned by many different users, is significantly different from the centralized organization of a file server, where everything is under the control of a small number of system administrators.

To address this problem, AODocs uses the Google Drive API to automatically transfer the ownership of files to a system account, and thus create a sort of “managed area” within Google Drive. With the Google Drive API, AODocs has complete control over the folder structure and the permissions of files owned by this system account. AODocs can be deployed in one click from the Google Apps Marketplace, which makes our application visible (and easy to try out!) for every Google Apps administrator in the world.

Companies who want to store their files on Google Drive may be concerned about losing control of their data (e.g. access to files being lost when an employee leaves the company) and controlling sharing permissions.

AODocs uses a single system account (i.e. a Google Apps account belonging to the customer’s domain, but not used by any human person) as a “proxy” to control the files. When a Google Drive files is added to an AODocs library, the ownership of the file is transferred to the AODocs system account and the file’s writersCanShare attribute is set to false, so that only AODocs is able to modify the file’s permissions afterwards.

To change the ownership of the file, we check if the system account can already access the file, and then either insert a new “owner” permission on it or use the Permissions.update method with the transferOwnership flag:

public void changeOwner(String user, String fileId, String newOwner) {
// Find what is the current permission of the new owner on the file
Permission newOwnerPermission = null;
PermissionList permissionList = RetriableTask.execute(new DrivePermissionListTask(drive.permissions().list(fileId)));
newOwnerPermission = findPermission(permissionList, newOwner);

if (newOwnerPermission == null) {
// New owner is not in the list, we need to insert it
newOwnerPermission = new Permission();
Drive.Permissions.Insert insert = drive.permissions().insert(fileId, newOwnerPermission);
RetriableTask.execute(new DrivePermissionInsertTask(insert));
} else {
// New owner is already in the list, update the existing permission
Drive.Permissions.Update update = drive.permissions().update(fileId, newOwnerPermission.getId(), newOwnerPermission);
RetriableTask.execute(new DrivePermissionUpdateTask(update));

Since all the files are owned by the system account, AODocs completely controls the lifecycle of the file (how they are created, in which folder they are located, who can change their permissions, who can delete them, etc). AODocs can thus provide higher-level document management features on top of Google Drive, such as configuring the retention time of deleted files, limiting external sharing to a whitelist of “trusted external domains”, or recording an audit log of file modifications.

As illustrated in the code snippet above, AODocs relies on the Google Drive API to perform all the operations on the managed files. The main challenge we had when using the Drive API was to properly handle all the error codes returned by the API calls, and make sure we make the difference between fatal errors that should not be tried again (for example, permission denied on a file) and the temporary errors that should be re-tried later (for example, “rate limit exceeded”). To handle that, we have encapsulated all our Google Drive API calls (we are using the Java client library) into a class named RetriableTask, which is responsible for handling the non-fatal errors and automatically retry the API calls with the proper exponential back-off. Here is a simplified version:

public class RetriableTask implements Callable {
private final Callable task;

@Override public T call() {
T result = null;
try {
startTime = System.currentTimeMillis();
result =;
} catch (NonFatalErrorException e) {
if (numberOfTriesLeft > 0) {
// Wait some time, using exponential back-off in case of multiple attempts

// Try again
result = call();
} else {
// Too many failed attempts: now this is a fatal error
throw new RetryException();
} catch (FatalErrorException e) {
// This one should not be retried
return result;

AODocs is designed to work seamlessly with Google Drive, and our top priority is to leverage all the integration possibilities offered by the Google APIs. We are very excited to see that new features are added very often in the Admin SDK, the Google+ API, the Drive API that will allow AODocs to provide more options to system administrators and improve the experience for our end users.

Thomas Gerber profile

Thomas is the CTO of Altirnao. Before founding Altirnao, Thomas has led a team of senior technologists and architects on High Availability/High Performance implementations of enterprise software.

Introducing the Google Drive Android API

Author PhotoBy Magnus Hyttsten, Developer Advocate, Google Drive

With today's developer preview of the Google Drive Android API in Google Play Services 4.1, you can add the convenience of Google Drive cloud storage to your apps without breaking a sweat.

While Drive integration on Android was possible in the past, the new API creates a faster, seamless experience that enables your apps to integrate with the Drive backend within minutes.

The new API offers a number of benefits:

1. Transparent use and syncing of local storage

The Google Drive Android API temporarily uses a local data store in case the device is not connected to a network. So, no need to worry about failed API calls in your app because the user is offline or experiencing a network connectivity problem. Data stored locally in this fashion will automatically and transparently be stored in the Google Drive cloud by Android’s sync scheduler when connectivity is available to minimize impact on battery life, bandwidth, and other resources.

2. Designed for Android and available everywhere

The API was developed for Android and conforms to the latest Android design paradigms, such as using the new uniform client API GoogleAPIClient. And being part of the latest release of Google Play Services provides additional benefits:
  • There’s minimal impact on the weight of your apps. As the client library is a stub to Google Play Services, incorporating the API has minimal impact on the size of your .apk binaries, resulting in faster downloads, fewer updates, and smaller execution footprint.
  • User files are automatically synced between different devices (provided the app has the same namespace and is signed with the same key).
  • Any device running the Gingerbread or later releases of Android and Google Play Services will automatically have support for the Google Drive Android API.

3. User interface components

File picker and creator user interface components are provided with this initial release of the Google Drive Android API, enabling users to select files and folders in Google Drive.

For example, the file picker is implemented as an Intent and allows you develop a native Android user experience with just a couple lines of code. This following code snippet launches the picker and allows the user to select a text file:
// Launch user interface and allow user to select file
IntentSender i = Drive.DriveApi
.setMimeType(new String[] { “text/plain” })
startIntentSenderForResult(i, REQ_CODE_OPEN, null, 0, 0, 0);

The result is provided in the onActivityResult callback as usual.

4. Direct access to Drive functionality

You may be wondering how the Google Drive Android API relates to the Storage Access Framework released as part of Android 4.4 KitKat.

The Storage Access Framework is a generic client API that works with multiple storage providers, including cloud-based and local file systems. While apps can use files stored on Google Drive using this generic framework, the Google Drive API offers specialized functionality for interacting with files stored on Google Drive — including access to metadata and sharing features.

Additionally, as part of Google Play services the Google Drive APIs are supported on devices running Android 2.3 Gingerbread and above.

How to get started

As you incorporate the Google Drive Android API into your apps, we hope it makes your life a little bit easier, and enables you to create fun, powerful apps that take advantage of all that Android and Google Drive can do together.

For more information visit our documentation or explore our API demo and other sample applications on the official Google Drive GitHub repository.

Also check out the official launch video:

Let’s keep the discussions going on +GoogleDrive, and Stack Overflow (google-drive-sdk).

Magnus Hyttsten is a Developer Advocate on the Google Drive team. Beyond work, he enjoys trying out new technologies, thinking about product strategies, and exploring California.

Posted by Scott Knaster, Editor

Cross posted on the Google Developers Blog.

New security management features for domain users with the Admin SDK

We launched the Admin SDK in May as a new way for developers to build customized administrative tools for organizations that use Google Apps. A top priority for most administrators is keeping their users safe. Today, we're adding new security management features to the Directory API to help administrators manage:

These new utilities allow Google Apps administrators to programmatically manage end-user access to third party applications, and enable third party developers to build new security management features in their applications.

As an example, FlashPanel, a popular tool used by Google Apps administrators, is using these new features to allow domain admins to review installed applications and manage or revoke access to them. The Apps Explorer in FlashPanel allows admins to see which are the most installed apps in his domain or use a filter to review applications by type of permissions (Drive, GMail, etc). It also allows admins to review the number of users who have granted access to a particular application.

The screenshot below shows an example of FlashPanel’s customized view of third-party application installs.

In FlashPanel’s integration, admins have the power to whitelist or blacklist apps, as shown below.

The Directory API now also provides the ability to manage admin notifications that are delivered to the Admin Console. Currently, admins receive notifications for events that affect their domains such as users approaching their storage limits or monthly bills that are due. Now you can use the API to list notifications, update their read status, or pull them into custom tools.

If you are interested in using these new endpoints, please refer to the Directory API documentation.

Ajay Guwalani  

Ajay Guwalani is Product Manager on Google Apps Admin APIs. His current focus is to build next generation admin APIs to make enterprise developers and admins happy.

Your apps + Google Apps = awesome

In 2013, we have made a lot of enhancements to our developer ecosystem. From the Admin SDK to the Google+ API for Domains, we've provided developers with better tools to build applications that integrate with, and add functionality to, Google Apps.

We are starting to roll out some significant changes that will make it easier for developers to build, deploy, and market applications for domain installation. This is a major improvement to our existing Google Apps Marketplace experience that we originally launched in 2010. You can get started right away by following our documentation here.

Some of the major enhancements in the new Google Apps Marketplace:

Improved security — Domain admins can install and authorize your applications for specific organizational units rather than the whole domain.
Consistent development experience — Use OAuth 2.0 for authorization and manage Google APIs in the Google Developer console.
Test before publishing — Test your app easily using the “Test Install” button in the Google Developers console vs. having to publish a live app.
Simplified publishing experience — Publish to the Chrome Web Store to use a single app listing for apps that work with both Google Drive and Google Apps for Business.
Deeper integration — Integrate with services like Google Drive and Google+ and into Google’s new app launcher.
Easier discoverability — Domain admins can discover your great apps directly from the Admin console.

We love our developers who are building third-party solutions for Google users. Please provide feedback on how we can improve the experience and help you connect with over 5 million companies that use Google Apps to improve how they get work done. Here are some great apps to get you inspired - Promevo gPanel,, UberConference, AODocs, Spanning Calendar Undelete, Flashpanel, and MindMeister. Get started with your Google Apps integration today!

Arun Nagarajan   profile

Arun is a Developer Advocate on Google Apps. Arun works closely with the community of partners, customers and developers to help them build compelling applications on top of Google Apps. Arun is originally from the Boston area and enjoys basketball and snowboarding.

Email address validation with Actions in the Inbox and Mandrill

We launched Actions in the Inbox at Google I/O 2013 as a quick way for users to get things done directly from Gmail. Integrating with this technology only requires adding some markup to an email to define what the message is about and what actions the user can perform.

We support a variety of action types covering common scenarios such as adding a movie to a queue, product reviews, or other even pre-defined requests. Especially popular with senders is the One-Click Action to validate a user’s email address, as shown below:

If you are using Mandrill, the email infrastructure service from MailChimp, writing a Python app to send one of those emails, only takes a few lines of code! Take a look at this example:

import mandrill

# Replace with your own values
SUBJECT = 'Please validate your email address'

   <script type='application/ld+json'>
     "@context": "",
     "@type": "EmailMessage",
     "action": {
       "@type": "ConfirmAction",
       "name": "Confirm Registration",
       "handler": {
         "@type": "HttpActionHandler",
         "url": ""
   <p>Please click on this link to validate your email address:</p>
   <p><a href=""></a></p>

# Instantiate the Mandrill client with your API Key
mandrill_client = mandrill.Mandrill(API_KEY)

message = {
'subject': SUBJECT,
'from_email': FROM_ADDRESS,
'to': [{'email': TO_ADDRESS}],

result = mandrill_client.messages.send(message=message)

To run this app, just replace the API key with the credentials from your Mandrill account and configure the sender and recipient addresses. You should also edit the HTML content to provide your action handler URL, and customize the messaging if you want.

You can use Actions in the Inbox to reduce the friction and increase the conversion rate. Please note that you are not limited to validating email addresses: you can also review products and services, reply to event invitations, and much more.

For more information, please visit our documentation at You can also ask questions on Stack Overflow, with the tag google-schemas.

Claudio Cherubino   profile | twitter | blog

Claudio is an engineer in the Gmail Developer Relations team. Prior to Google, he worked as software developer, technology evangelist, community manager, consultant, technical translator and has contributed to many open-source projects. His current interests include Google APIs, new technologies and coffee.

Monitor user logins, storage consumption and apps usage with the Admin SDK

Security is a top priority for Google, just as it is for many of our Google Apps customers. As a domain administrator, a big part of keeping your users safe is knowing when and how they are using their accounts. Since we launched the Admin SDK Reports API in June, we've continued to add features to let you more easily visualize Google Apps' usage and security in your domain. These new features include:

Security Reports

  • Login audit—View all web browser based logins with IP information for all users in your domain. You can use this data to monitor all successful, failed, and suspicious logins in your domain.
  • Authorized applications—View a list of third-party applications that users in your domain have shared data with. Gain visibility into how many users are accessing each application. Revoke access to specific apps using the security tab on Admin console.

Usage Reports

  • Storage quota—View user-level quota usage. This is available both as total usage and split by Gmail, Drive and Google+ photos for every user in the domain. Monitor which users are nearing their quota limits and acquire more storage if necessary.
  • Google+ usage—View 1-day, 7-day and 30-day active Google+ usage in your domain. See the number of Hangouts attended by users in your domain.

Refer to the Reports API documentation for more details on how to use the Reports API and to see what is possible with all of our entire Admin SDK.

Rishi Dhand profile

Rishi Dhand is a Product Manager on the Google Apps for Business team. In addition to working on data migration features, he also works on the Google Apps administration platform with focus on building new security and admin reporting features. In his free time, he enjoys playing squash and badminton.

Connect your organization to Google+ using the Google+ Domains API

Google+ make it easy for Google Apps customers to connect and share within their organisation and encourage collaboration between teams. Today we’re launching an update to the Google+ Android app that includes a number of new features for Google Apps customers, and a new developer offering, the Google+ Domains API.

The Google+ Domains API allows Google Apps customers to integrate Google+ into their existing tools and processes, and allows enterprise software vendors to access Google+ from their products. Applications using the Google+ Domains API can act on behalf of Google Apps users to share posts within the same domain, comment on posts shared within the domain, and manage Circles. In addition, the Google+ Domains API enables Google Apps domain administrators to pre-populate the Circles of new employees, or review sharing activity.

For example, Ocado is building a tool that uses the Google+ Domains API to regularly sync team membership stored in Active Directory with the circles of their employees. This will ensure that every employee always has an up to date circle containing the other members of their team. Cloudlock is using the Google+ Domains API to add support for Google+ to its suite of data loss prevention, governance, and compliance applications.

Any developer can begin developing with the Google+ Domains API today. However only members of a Google Apps domain can use Google+ Domains API applications. To get started check out the documentation. If you have any questions, you can consult the google-plus tag on Stack Overflow, or join the “Developing with Google+” Google+ Community.

Posted by Thor Mitchell, Product Manager, Google+ API

Cross posted on the Google+ Developers blog.

Introducing a New Version of the Email Migration API

Today, we are pleased to announce a new release of the Email Migration API. This version of the API provides a simple RESTful interface with several enhancements that make it even easier to write client applications to migrate email to Google Apps.

This API is now part of our Admin SDK, which is useful for managing applications for Google Apps users through the Google APIs Console. Additionally, the Email Migration API v2 now includes support for:
  • Delegated administrators
  • OAuth 2.0
  • Media uploads
The new API also provides support for migrating additional email metadata (such as folders and labels) from existing email systems into Google Apps. For example, a user’s email stored in a nested folder named engineering/backend-support can be migrated with the label engineering-backend-support to retain the previous organization structure.

For more information about the API, visit the the Getting Started guide or explore the API Reference.

Greg Knoke Google+

Greg Knoke is a technical writer in the Google Drive Developer Relations Team. Prior to joining Google, he worked as a scientist developing image and signal processing algorithms. His current interests include new technologies, content management, information architecture, cooking, music, and photography.