Google Cloud Platform – Overview of G Suite APIs

Many of you know how to use Gmail, Google Drive, and Docs, and that’s great. But can you code them too? In this article we aim to learn about G Suite as another tool, giving you the ability to code those apps you know so well. 

Productivity tools like a word processor, spreadsheets, and presentation software in the form of Google Docs, Sheets, and Slides. Add in Gmail, Google Drive, Calendar, Google Forms, Hangouts and you’ve got the core components of G Suite. In addition to that, the paying customers get even more tools. While many of you know how to use G Suite, behind each app is a developer API, meaning you can code Gmail, Google Drive, Calendar, Docs, Sheets, and Slides. 

G Suite is one part of Google Cloud along with the Google Cloud Platform, like, compute, storage, networking, security, serverless, and machine learning tools that you can rent in the cloud. In addition to Cloud, Google has other apps for users, like Search, Chrome, YouTube, and Android.

Google has made lots of techs available to us in the form of APIs. We can use them to build our next web app, mobile app, or more likely both. The hub of Google API activity is the Google Cloud Platform console that you access at console.cloud.google.com. It’s where you manage your apps, called “projects.” Most of its features are for Google Cloud Platform, like choosing which GCP tools to use, managing GCP billing, managing other project developers, and selecting the APIs you’ll use. Only GCP users need to use the first pair.

 Now, you don’t have to worry about billing in the console because G Suite and GCP APIs are built differently. GCP services are pay-per-use. That’s what the billing component in the console is for. But G Suite API usage is at no additional charge on top of its subscription fee, whether it’s the pay-for Business Edition or the free Gmail Consumer version. 

Let’s take a look at the API Manager. This developer’s console has three tabs. The Dashboard is to see stats on your app, like how much traffic you’re getting, the number of errors it’s generating, and how fast it responds to users. 

The second tab is to enable or disable which APIs to use. None of the G Suite APIs are on by default. So pick and choose the ones to toggle on or off. 

The last tab is to create credentials like API keys and OAuth clients.

You can access the API Manager directly at console.developers.google.com. To access Google APIs, we can use Google’s client libraries. Here we will take an example in Python, but many other languages are supported, and all the client libraries can be downloaded.

There are two types of APIs, simple and authorized. Simple APIs are for accessing public data, like searching for places on Google Maps, querying for YouTube videos, or sending a sentence to the Cloud Natural Language API. However, if your code requires access to user or application data, you need authorized access. For user data, that’s user authorization. And for app data, that’s service account authorization. Both are basically the same except for who owns that data.

  Regardless, to get started with a new project, go to the API Manager and create a project or reuse an existing one.

 Then enable the G Suite or GCP APIs you wish to use.

Finally, create the appropriate credentials to talk to Google APIs. 

Since most G Suite data is owned by users, you’ll create OAuth 2 client ID. However, if your data is owned by an app or you’re using GCP services, create service account OAuth credentials instead.

In either case, download the JSON file with those credentials once they’ve been created because your code needs this to talk to Google servers. As Google is always trying to improve the libraries. So while the names may change, the structure will stay consistent. This example is in Python:

Python3

from googleapiclient import discovery
from httplib2 import Http
from oauth2client import

SCOPES = ... # at least one (string or array of strings)

# 'storage.json' - where to store OAuth2 tokens from API
# 'client_secret.json' - OAuth2 client ID & secret
store = file.Storage('storage.json)
creds = store.get()
if not creds or creds.invalid:
    flow = client.flow_from_clientsecrets('client_secret.json',SCOPES)
    creds = tools.run_flow(flow, store)

# create API service endpoint
SERVICE = discovery.build(API, VERSION, http=creds.authorize(HTTP()))

But regardless of what language you use, after your imports are the permission scopes that you want your user to grant to your app.

Python3

SCOPES = ... # at least one (string or array of strings)

Next is a security code. Now, authorized APIs require valid OAuth tokens, and this block checks to see if you have them. If not, it puts together your credentials plus the permission scopes and prompts the user for it. It’s that OAuth permissions box that you see whenever you run the app the first time.

Python3

store = file.Storage('storage.json)
creds = store.get()
if not creds or creds.invalid:
    flow = client.flow_from_clientsecrets('client_secret.json',SCOPES)
    creds = tools.run_flow(flow, store)

Once you get the OK from your user, create an endpoint to talk to the API. Service account auth is a bit simpler because you don’t have to ask a user to grant permissions. The owner of the data, which could be you, will have already trusted you enough to create service account credentials for you.

Python3

SERVICE = discovery.build(API, VERSION, http=creds.authorize(HTTP()))

Whichever you’re using, the auth code generally stays the same. Now, the only things that really change are the bolded lines like the permissions scopes, and what APIs you use.

Everything happens in a request-response workflow. Your app makes a request, credentials are confirmed, the request to service and response is returned. It’s very much of a client-server model.