G Suite Developers Blog

New security protections to reduce risk from unverified apps

2017-07-18T10:00:00.000-07:00

Posted by Naveen Agarwal, Identity team and Wesley Chun (@wescpy), Developer Advocate, G Suite

We’re constantly working to secure our users and their data. Earlier this year, we detailed some of our latest anti-phishing tools and rolled-out developer-focused updates to our app publishing processes, risk assessment systems, and user-facing consent pages. Most recently, we introduced OAuth apps whitelisting in G Suite to enable admins to choose exactly which third-party apps can access user data.

Over the past few months, we’ve required that some new web applications go through a verification process prior to launch based upon a dynamic risk assessment.

Today, we’re expanding upon that foundation, and introducing additional protections: bolder warnings to inform users about newly created web apps and Apps Scripts that are pending verification. Additionally, the changes we're making will improve the developer experience. In the coming months, we will begin expanding the verification process and the new warnings to existing apps as well.

Protecting against unverified apps

Beginning today, we’re rolling out an “unverified app” screen for newly created web applications and Apps Scripts that require verification. This new screen replaces the “error” page that developers and users of unverified web apps receive today.

The “unverified app” screen precedes the permissions consent screen for the app and lets potential users know that the app has yet to be verified. This will help reduce the risk of user data being phished by bad actors.

The "unverified app" consent flow

This new notice will also help developers test their apps more easily. Since users can choose to acknowledge the ‘unverified app’ alert, developers can now test their applications without having to go through the OAuth client verification process first (see our earlier post for details).

Developers can follow the steps laid out in this help center article to begin the verification process to remove the interstitial and prepare your app for launch.

Extending security protections to Google Apps Script

We’re also extending these same protections to Apps Script. Beginning this week, new Apps Scripts requesting OAuth access to data from consumers or from users in other domains may also see the "unverified app" screen. For more information about how these changes affect Apps Script developers and users, see the verification documentation page.

Apps Script is proactively protecting users from abusive apps in other ways as well. Users will see new cautionary language reminding them to “consider whether you trust” an application before granting OAuth access, as well as a banner identifying web pages and forms created by other users.

Updated Apps Script pre-OAuth alert with cautionary language

Apps Script user-generated content banner

Extending protections to existing apps

In the coming months, we will continue to enhance user protections by extending the verification process beyond newly created apps, to existing apps as well. As a part of this expansion, developers of some current apps may be required to go through the verification flow.

To help ensure a smooth transition, we recommend developers verify that their contact information is up-to-date. In the Google Cloud Console, developers should ensure that the appropriate and monitored accounts are granted either the project owner or billing account admin IAM role. For help with granting IAM roles, see this help center article.

In the API manager, developers should ensure that their OAuth consent screen configuration is accurate and up-to-date. For help with configuring the consent screen, see this help center article.

We’re committed to fostering a healthy ecosystem for both users and developers. These new notices will inform users automatically if they may be at risk, enabling them to make informed decisions to keep their information safe, and will make it easier to test and develop apps for developers.

Identifying app usage in your Google Drive audit logs

2017-07-12T10:00:00.000-07:00

Posted by Rio Akasaka, Product Manager, Google Drive and Wesley Chun (@wescpy), Developer Advocate, G Suite

If you’re a G Suite admin (or a developer creating apps for admins), it’s important to understand the various applications your company’s employees are using and how they’re accessing them. Today, we’re making that easier by introducing app identification (i.e. originating_app_id) in the Google Drive audit logs within the Admin SDK Reports API.

Now, your apps will be able to determine whether an activity logged was performed by a user in the Drive Android app, Drive iOS app, Google Chrome, or through a variety of other third-party apps that leverage, modify or create files within Google Drive, like Smartsheet or Asana. This will give you a better sense of the apps being used in your organization, as well as the extent and context of that usage.

Note that App IDs that show up in the logs will be numeric. Should you want to retrieve app names, a separate request using the Google Drive REST API is needed. If you already retrieve information through the Drive activity request, you should start seeing the originating_app_ids show up in your logs. Here are a pair of HTTP requests you can use to query this information:

GET 
https://www.googleapis.com/admin/reports/v1/activity/users/userKey

GET 
https://www.googleapis.com/admin/reports/v1/activity/users/all/applications/drive

To learn more about this new feature, take a look at the documentation, then integrate into your code so you and other G Suite admins can gain a better understanding of app usage in your domain(s). We look forward to seeing what you build!

Google People API now supports updates to Contacts and Contact Groups

2017-07-05T14:00:00.000-07:00

Posted by Amos Yuen, Software Engineer, and Wesley Chun (@wescpy), Developer Advocate, G Suite

Starting today, the Google People API will get new endpoints for contacts and contact groups. Last year, we launched the Google People API with read-only endpoints with plans to eventually replace the old Contacts API. We’re one step closer to that goal by adding write endpoints that allow developers to create, delete and update a single contact. In addition, there are new contact group endpoints that allow developers to read and write contact groups.

Applications need to be authorized to access the API so to get started, you will need to create a project on the Google Developers Console with the People API enabled to get access to the service. All of the steps to do so are here. If you’re new to the Google APIs and/or the Developers Console, check out this video, the first in a series of videos to help you get up-to-speed.

Once you’re authorized, you can simply create new contacts like this (using the Google APIs Client Library for Java):

Person contactToCreate = new Person();

List names = new ArrayList<>();
names.add(new Name().setGivenName("John").setFamilyName("Doe"));
contactToCreate.setNames(names);

Person createdContact =
    peopleService.people().createContact(contactToCreate).execute();

The scope your app needs to authorize with is https://www.googleapis.com/auth/contacts. Full documentation on the people.create method is available here. You can update an existing contact like this:

String resourceName = "people/c12345"; // existing contact resource name
Person contactToUpdate = peopleService.people().get(resourceName)
    .setPersonFields("names,emailAddresses")
    .execute();

List emailAddresses = new ArrayList<>();
emailAddresses.add(new EmailAddress().setValue("john.doe@gmail.com"));
contactToUpdate.setEmailAddresses(emailAddresses);

Person updatedContact = peopleService.people().updateContact(contactToUpdate)
    .setUpdatePersonFields("emailAddresses")
    .execute();

Full documentation on the people.update method is available here. We look forward to seeing what you can do with these new features allowing you to modify contacts. To learn more about the People API, check out the official documentation here.

Modifying events with the Google Calendar API

2017-06-29T10:00:00.000-07:00

Posted by Wesley Chun (@wescpy), Developer Advocate, G Suite

You might be using the Google Calendar API, or alternatively email markup, to insert events into your users’ calendars. Thankfully, these tools allow your apps to do this seamlessly and automatically, which saves your users a lot of time. But what happens if plans change? You need your apps to also be able to modify an event.

While email markup does support this update, it’s limited in what it can do, so in today’s video, we’ll show you how to modify events with the Calendar API. We’ll also show you how to create repeating events. Check it out:

Imagine a potential customer being interested in your product, so you set up one or two meetings with them. As their interest grows, they request regularly-scheduled syncs as your product makes their short list—your CRM should be able to make these adjustments in your calendar without much work on your part. Similarly, a “dinner with friends” event can go from a “rain check” to a bi-monthly dining experience with friends you’ve grown closer to. Both of these events can be updated with a JSON request payload like what you see below to adjust the date and make it repeating:

var TIMEZONE = "America/Los_Angeles";
var EVENT = {
    "start": {"dateTime": "2017-07-01T19:00:00", "timeZone": TIMEZONE},
    "end":   {"dateTime": "2017-07-01T22:00:00", "timeZone": TIMEZONE},
    "recurrence": ["RRULE:FREQ=MONTHLY;INTERVAL=2;UNTIL=20171231"]
};

This event can then be updated with a single call to the Calendar API’s events().patch() method, which in Python would look like the following given the request data above, GCAL as the API service endpoint, and a valid EVENT_ID to update:

GCAL.events().patch(calendarId='primary', eventId=EVENT_ID,
    sendNotifications=True, body=EVENT).execute()

If you missed it, check out this video that shows how you can insert events into Google Calendar as well as the official API documentation. Also, if you have a Google Apps Script app, you can programmatically access Google Calendar with its Calendar service.

We hope you can use this information to enhance your apps to give your users an even better and timely experience.

VIDEO: Part 1—Introducing Team Drives for developers

2017-06-07T12:00:00.000-07:00

Posted by Hodie Meyers, Product Manager, Google Drive, and Wesley Chun (@wescpy), Developer Advocate, G Suite

Enterprises are always looking for ways to operate more efficiently, and equipping developers with the right tools can make a difference. We launched Team Drives this year to bring the best of what users love about Drive to enterprise teams. We also updated the Google Drive API, so that developers can leverage Team Drives in the apps they build.

In this latest G Suite Dev Show video, we cover how you can leverage the functionality of Team Drives in your apps. The good news is you don’t have to learn a completely new API—Team Drives features are built into the Drive API so you can build on what you already know. Check it out:

By the end of this video, you‘ll be familiar with four basic operations to help you build Team Drives functionality right in your apps:

How to create Team Drives
How to add members/users to your Team Drives
How to create folders in Team Drives (just like creating a regular Drive folder)
How to upload/import files to Team Drives folders (just like uploading files to regular folders)

The Drive API can help a variety of developers create solutions that work with both Google Drive and Team Drives. Whether you’re an Independent Software Vendor (ISV), System Integrator (SI) or work in IT, there are many ways to use the Drive API to enhance productivity, help your company migrate to G Suite, or build tools to automate workflows.

Team Drives features are available in both Drive API v2 and v3, and more details can be found in the Drive API documentation. We look forward to seeing what you build with Team Drives!

Google I/O session recap: how to build custom apps with App Maker

2017-06-01T10:00:00.000-07:00

Posted by Geva Rechav, Product Manager, App Maker

Every company has workflows and processes that are unique to its business, customers and employees. Often, these are captured manually within large spreadsheets or ad-hoc databases with macros and scripts. But what if they could be turned into custom business apps instead? Apps that provide useful UIs and distinct user roles, while helping to minimize data entry errors and increase productivity?

This year at Google I/O, I shared reasons why businesses should use App Maker—our low-code, application development tool that lets companies quickly build custom apps in G Suite. Check it out here:

And for those who’d like more detail, here is a recap of my presentation.

Closing enterprise “app gaps” with App Maker

“App gaps” are a reality for most companies, even those that embrace major SaaS products. Think about the edge cases that aren’t addressed with a standard CRM offering like conducting territory planning or tracking asset performance.

We experienced similar gaps at Google. A few years ago, our HR recruiters were overwhelmed with the thousands of monthly interviews that each generated lengthy feedback reports from multiple interviewers. This volume made it difficult for hiring committees to calibrate candidates and make timely decisions, and resulted in delayed responses. To fix this, our IT team decided to build an app by cobbling elements from our own infrastructure.

Over time, more app requests came in from other parts of Google, so we created App Maker. What started as a handful of apps within Google, evolved into nearly 400 internal apps used by thousands. Plus, the majority of these apps were built by non-engineers outside of IT.

Today, App Maker gives software engineers and citizen developers—like business analysts or coding enthusiasts—the ability to quickly build and deploy apps to get around their workflow challenges.

How does it work?

App Maker makes it easy to build apps in days, not months, because of its easy data-binding and drag-and-drop UI design. You can also integrate your apps with various data sources, Google services or APIs to cover broad legacy assets. Any app you create is also a part of Drive in G Suite so your data never leaves your domain.

Here’s how to build an App Maker app in three steps:

Define your data models, by importing existing Google Sheets to App Maker, connecting to Google Cloud SQL instances, or manually defining custom objects field by field.
Build your UI by adding pre-built components like data entry forms, report templates and easily create event triggers and application flows.
Optionally, add open source HTML, CSS and JavaScript to run on the client UI and on the app server, implementing custom functionality that’s not provided out-of-the-box.

App Maker is currently in Early Adopter Program (EAP) for every G Suite Business customer. To get started, apply here.

Ideas to get started

By now you’re probably wondering what you can build. Well, based on our customers’ experience, here are some good starting points:

If you have a large Sheet with more than a handful of users updating it regularly: Sheets usually have an underlying workflow. An App Maker app will provide a better UI for it—showing the workflow visually, prompting for actions and eliminating data entry errors.
If you perform recurring bulk operations in Calendar or Gmail: Say an employee joins or leaves a department, you can build an App Maker app to generate the appropriate bulk-operations in a few clicks.
If your company is already using Apps Script and BigQuery: This means you’ve already invested in customizing workflows. App Maker can increase the velocity of developing custom apps.

Go build your apps with App Maker in G Suite—sign up for the EAP today.

Updating developer identity guidelines and registration processes to protect users

2017-05-11T12:00:00.000-07:00

Posted by Naveen Agarwal, Identity Team
(x-posted from Google Developers)

Last week, we took immediate action to protect users from a phishing attack that attempted to abuse the OAuth authorization infrastructure.

Today, we’re supplementing those efforts to help prevent these types of issues in the future. These changes may add some friction and require more time before you are able to publish your web application, so we recommend that you plan your work accordingly.

Updating app identity guidelines

As our Google API user data policy states, apps must not mislead users. For example, app names should be unique to your application and should not copy others'.

To further enforce this policy, we are updating our app publishing process, our risk assessment systems, and our user-facing consent page in order to better detect spoofed or misleading application identities. You may see an error message as you’re registering new applications or modifying existing application attributes in the Google API Console, Firebase Console, or Apps Script editor as a result of this change.

New review processes and restrictions on web apps requesting user data

We have also enhanced our risk assessment for new web applications that request user data.

Based on this risk assessment, some web applications will require a manual review. Until the review is complete, users will not be able to approve the data permissions, and we will display an error message instead of the permissions consent page. You can request a review during the testing phase in order to open the app to the public. We will try to process those reviews in 3-7 business days. In the future, we will enable review requests during the registration phase as well.

You can continue to use your app for testing purposes before it is approved by logging in with an account registered as an owner/editor of that project in the Google API Console. This will enable you to add additional testers, as well as initiate the review process.

We also recommend developers review our earlier post outlining their responsibilities when requesting access to user data from their applications. Our teams will continue our constant efforts to support a powerful, useful developer ecosystem that keeps users and their data safe.

Create quizzes in Google Forms with Apps Script

2017-04-27T10:00:00.000-07:00

Posted by Tynia Yang, Software Engineer, Google Forms

Last year, we launched Quizzes in Google Forms to help teachers and students take assessment to scale. Using Quizzes, teachers are able to automate testing and give feedback to students faster by having Forms check responses against correct answers automatically. Today, we are making that functionality available to developers by extending the Google Apps Script Forms Service. With this feature, you can create and customize quizzes programmatically with Apps Script.

More specifically:

Create quizzes
Assign point values and correct answers for questions
Implement custom grading schemes

Let’s take a look at an example use case and relevant code snippet.

Creating an auto-graded question

Multiple choice, checkbox and dropdown questions can be auto-graded, which means students can see their grades immediately upon submission. This is done by designating which options are the correct answer. Teachers can also set automatic feedback to show correct or incorrect responses, as well as assign point values to the question.

Here is the Apps Script code that lets you create the quiz above:

function createGradedCheckboxQuestionWithAutofeedback() {
  // Make sure the form is a quiz.
  var form = FormApp.getActiveForm();
  form.setIsQuiz(true);

  // Make a 10 point question and set feedback on it
  var item = FormApp.getActiveForm().addCheckboxItem();
  item.setTitle("What flavors are in neapolitan ice cream?");
  item.setPoints(10);
  // chocolate, vanilla, and strawberry are the correct answers
  item.setChoices([
    item.createChoice("chocolate", true),
    item.createChoice("vanilla", true),
    item.createChoice("rum raisin", false),
    item.createChoice("strawberry", true),
    item.createChoice("mint", false)
  ]);
  // If the respondent answers correctly, they'll see this feedback when they view 
  //scores.
  var correctFeedback = FormApp.createFeedback()
      .setText("You're an ice cream expert!")
      .build();
  item.setFeedbackForCorrect(correctFeedback);
  
  // If they respond incorrectly, they'll see this feedback with helpful links to 
  //read more about ice cream.
  var incorrectFeedback = FormApp.createFeedback()
      .setText("Sorry, wrong answer")
      .addLink(
        "https://en.wikipedia.org/wiki/Neapolitan_ice_cream",
        "Read more")
      .build();
  item.setFeedbackForIncorrect(incorrectFeedback);
}

For more details on what you can build with the Apps Script Forms Service, review the documentation, ask questions on Stack Overflow or in the G+ community, and let us know what else you’d like to see using the new public issue tracker for Apps Script.

Using field masks with update requests to Google APIs

2017-04-20T13:30:00.000-07:00

Posted by Wesley Chun (@wescpy), Developer Advocate, G Suite

We recently demonstrated how to use field masks to limit the amount of data that comes back via response payloads from read (GET) calls to Google APIs. Today, we’ll focus on a different use case for field masks: update requests.

In this scenario, field masks serve a different, but similar purpose—they still filter, but function more like bitmasks by controlling which API fields to update. The following video walks through several examples of update field mask usage with both the Google Sheets and Slides APIs. Check it out.

In the sample JSON payload below, note the request to set the cells' bold attribute to true (per the cell directive below), then notice that the field mask (fields) practically mirrors the request:

{
    "repeatCell": {
        "range": {
            "endRowIndex": 1
        },
        "cell": {
            "userEnteredFormat": {
                "textFormat": {
                    "bold": true
                }
            }
        },
        "fields": "userEnteredFormat/textFormat/bold",
    }
}

Now, you might think, “is that redundant?” Above, we highlighted that it takes two parts: 1) the request provides the data for the desired changes, and 2) the field mask states what should be updated, such as the userEnteredFormat/textFormat/bold attribute for all the cells in the first row. To more clearly illustrate this, let’s add something else to the mask like italics. Here, the updated field mask now has both bold and italic fields:

"fields": "userEnteredFormat/textFormat(bold,italic)"

However, while both elements are in the field mask, we’ve only provided the update data for bold. There’s no data for italic setting specified in the request body. In this case, for all cells will be reset, meaning if the cells were originally italicized, those italics will be removed after this API request completes. And vice versa, if the cells were not italicized to begin with, they’ll stay that way. This feature gives developers the ability to undo or reset any prior settings on affected range of cells. Check out the video for more examples and tips for using field masks for update requests.

To learn more about using field masks for partial response in API payloads, check out this video and the first post in this two-part series. For one of the most comprehensive write-ups on both (read and update) use cases, see the guide in the Google Slides API documentation. Happy field-masking!

Using Google Sheets filters in Add-ons with Google Apps Script

2017-04-13T12:00:00.000-07:00

Posted by Bruce Mcpherson and Romain Vialard, Google Developers Experts, and posted by Wesley Chun (@wescpy), G Suite Developer Advocate

Developers using Google Apps Script can now access the richer feature set of the updated Google Sheets API with the recent launch of the Advanced Sheets Service. One key benefit of using an advanced service vs. native Apps Script objects, is that developers can access current API features (without having to wait for native support to come along). For example, the advanced service allows developers to access Sheets filters which make Add-ons more engaging.

Filter functionality

With the Sheets API, developers can already get filtered rows or set new filters on Sheets data. With the Advanced Sheet Service, developers can now have their Add-ons respect those filters and apply new filters to modify what data is visible in the Sheets UI. Plus, with any of the Apps Script advanced services, you can easily access the Sheets and other Google APIs without using the UrlFetch service nor managing the authorization flow that you’d otherwise have to perform if using the REST API directly. The snippet below will return the indexes of the filtered rows in a given Sheet. Note that it is also possible to retrieve the list of rows hidden manually, using the "hide row" menu item in Google Sheets, as indicated in the API documentation. In the code sample here, we’re only exposing rows hidden by filter.

 function getIndexesOfFilteredRows(ssId, sheetId) {
  var hiddenRows = [];
  
  // limit what's returned from the API
  var fields = "sheets(data(rowMetadata(hiddenByFilter)),properties/sheetId)";
  var sheets = Sheets.Spreadsheets.get(ssId, {fields: fields}).sheets;  
  
  for (var i = 0; i < sheets.length; i++) {
    if (sheets[i].properties.sheetId == sheetId) {
      var data = sheets[i].data;
      var rows = data[0].rowMetadata;
      for (var j = 0; j < rows.length; j++) {
        if (rows[j].hiddenByFilter) hiddenRows.push(j);
      }
    }
  }
  return hiddenRows;
}

The fields parameter in the code snippet limits what's returned in the Sheets API response, requesting only the values that matter to your app. For more information, check out this page in the Sheets API doc or this recent video on field masks.

See how some Add-ons use filtering

There are a number of Add-ons that use advanced filtering in Sheets. Here are some good examples:

Yet Another Mail Merge: this Add-on helps users send email campaigns from a spreadsheet and is built to process only the filtered rows of a Sheet. Let's say you have a list of people who are registered for an event, but you've only accepted some of these registrants and need to send an email confirmation. With Yet Another Mail Merge and the updated API, you can filter out people you don't approve to attend and the Add-ons skips them without sending confirmations.
Sankey Snip and Chord Snip: these Add-ons helps users create special chart types that aren't available in the Google Sheets UI. When respecting filters is enabled with these Add-ons, the charts will dynamically visualize filtered data. Check out the example below from the Chord Snip Add-on.

Of course the API also provides the ability to add, update or delete filters on a Sheet. This is useful if you want to quickly display rows with a specific status to your users. One example would be if you built a workflow approval Add-on. You can show the user rows that are waiting for approval. The snippet below applies the requested filter on a given Sheet—the API documentation describes a standard basic filter object:


function setSheetBasicFilter(ssId, BasicFilterSettings) {
  //requests is an array of batchrequests, here we only use setBasicFilter
  var requests = [
    {
      "setBasicFilter": {
        "filter": BasicFilterSettings
      }
    }
  ];
  Sheets.Spreadsheets.batchUpdate({'requests': requests}, ssId);
}

Yet Another Mail Merge, as many mass-mailing tools do, keeps track of all emails sent, opened and clicked. A tracking report is available in the spreadsheet sidebar, and clicking on the number of emails opened will automatically apply a filter to display only the matching rows—all rows with the status “opened.”

Now, you can determine filters applied in a Sheet directly through the Sheets API or through Apps Script apps and Add-ons using the Advanced Sheets Service, and continue to build the best experience for your users.

About the Authors

Romain Vialard is a Google Developer Expert. After some years spent as a G Suite consultant, he is now focused on products for G Suite and Google Apps users, including add-ons such as Yet Another Mail Merge and Form Publisher.

Bruce Mcpherson is a Google Developer Expert, an independent consultant, blogger and author of Going GAS, Google Apps Script for Beginners, and Google Apps Script for Developers.

New Google Drive metrics now accessible from Reports API

2017-04-05T11:40:00.000-07:00

Posted by Rio Akasaka, Product Manager, Google Drive and Wesley Chun (@wescpy), G Suite Developer Advocate

You might have read that we launched new metrics in the Admin SDK Reports API to help you gain reliable, easily-validated perspectives about users within your domain. Today, we're building on these features by giving administrators and developers even greater visibility into how files are shared both inside and outside of domain. These changes include:

New metrics to supplement the set of metrics we launched last year
New visibility information for audit events
Deprecation of existing metrics from the Reports API

New Metrics

We’ve created a new set of metrics to complete the set we launched last year. With these new metrics you can:

Gain insight into the visibility of files and their sharing state, which is useful for security and reporting. This will replace these older metrics:
```
num_docs_internally_visible, num_docs_externally_visible, num_docs_shared_outside_domain.
```
Report on product adoption within your domain with summary statistics about groups of users (collaborators, viewers, creators and sharers). Take advantage of key adoption metrics such as 1-, 7-, and 30-day active users for Google Drive, Docs, Sheets, Slides, Forms, Drawings and more.
Simplify your calculation of “what has changed” in your domain using delta metrics which pre-calculate changes in visibility and items owned.

New Visibility Information

Now, new visibility information is attached to every audit event which helps you quickly identify the permission change events that lead to files being shared differently both within and outside your domain. Learn more.

Deprecating Existing Metrics

While we’re aware of the need to have reliable and timely data about your domain’s users and files on Google Drive, Drive’s data and infrastructure has grown considerably, requiring us to make some difficult technical tradeoffs regarding metrics. As a result, today marks the beginning of a 12-month deprecation timeline that will retire these existing metrics from the Reports API and eventually the Admin Console. These metrics will no longer be available starting May 14, 2018.

To get started using the Reports API and see all the different types of metrics you can report on for your domain, check out the official documentation. We hope you find these features useful in your reporting.

Updates to end user consent for 3rd-party apps and Single Sign-on providers

2017-04-03T10:00:00.000-07:00

Posted by Rodrigo Paiva, Product Manager, Nicholas Watson, Software Engineer and Wesley Chun, Developer Advocate

At Google, we're mindful of keeping our users’ data and account information secure. So whether you're writing an app that requires access to user data or helping your users change their passwords, we’ll keep you up-to-date on policy changes, and now today, when it comes to consent and 3rd-party applications. Starting April 10, 2017, if you’re an application developer or a 3rd-party Single Sign-On (SSO) provider, your G Suite users may encounter a redirect when they authenticate with your identity service to make it clear to users which account they’re authenticating as well as the permissions they’re granting to applications.

These changes will occur on these platforms:

Google and 3rd-party applications on iOS
Mobile browsers on iOS and Android
Web browsers (Chrome, Firefox and other modern browsers)

Note that Android applications that use the standard authentication libraries are already prompting users to select appropriate account information, so they’re not impacted by these changes.

More visibility with new permission requests for your application

It’s important that your users are presented with account information and credential consent, and apps should make this process easy and clear. One new change that you may now see is that only non-standard permission requests will be presented in the secondary consent screen in your application.

Currently when an application requests permissions, all of them are displayed together. However, users should have greater visibility into permissions being requested beyond the standard “email address” and “profile” consent. By clicking to select their account, a user consents to these core permissions. The secondary consent screen will appear only if additional permissions are requested by the application.

Only non-standard permissions will be presented in the secondary consent screen that the user must approve.

Along with these changes, your application name will be more visible to users, and they can click-through to get your contact information. We recommend application developers use a public-facing email address so that users can quickly contact you for support or assistance. For more details, check out this developer guide.

If your application may also be used by G Suite customers that employ a 3rd-party Single Sign-On (SSO) service, we recommend that you utilize the hd and/or login_hint parameters, if applicable. Even with the changes to the 3rd-party SSO auth flow, these parameters will be respected if provided. You can review the OpenID Connect page in the documentation for more information.

Changes coming for 3rd-party SSO redirection

G Suite users may also notice redirection when signing into 3rd-party SSO providers. If no accounts are signed in, the user must confirm the account after signing in to the 3rd-party SSO provider to ensure that they’re signed in with the correct G Suite account:

The end user who has just signed in with one Google account should select that account as confirmation.

As mentioned, by clicking to select their account, a user is opting into “email address” and “profile” consent. Once the user consents to any additional non-standard permissions that may be requested, they will be redirected back to your application.

If the user is already signed in to one or more accounts that match the hd hint, the Account Chooser will display all of the accounts and require the user to select the appropriate G Suite account before being redirected to the 3rd-party SSO provider then back to your application:

A user who is signed into several Google accounts will be required to choose the appropriate account.

See updates starting April 2017

These changes will help your users understand their permissions more clearly across all platforms, whether they’re using Google or a 3rd-party SSO provider for authentication. We’ve started to roll out the new interstitial page on iOS devices, and changes for browsers will begin to roll out starting April 10, 2017.

Using field masks with Google APIs for partial response

2017-03-31T12:00:00.000-07:00

Posted by Wesley Chun, Developer Advocate, G Suite

When you write applications using Google APIs (not just G Suite ones, but most Google APIs including YouTube or Google Cloud Platform APIs), it's important to be mindful of the data that’s returned in the response payloads from API calls. If you're not, your apps are likely getting back much more data than they need which can affect the performance of your apps whether on mobile or a server backend.

That's why most Google APIs allow you to only filter the data you need from response payloads with field masks. To get you comfortable with field masks, we’ve put together a video to demonstrate their use with various Google APIs: With field masks, you can specify exactly what fields an API should return in its response payload by providing a fields or part parameter in your calls. And once the API knows what you want, it will likely spend less time assembling your response too. Here’s an example Python call to fetch your sender addresses using the Gmail API (if GMAIL is your service endpoint):

     addresses = GMAIL.users().settings().sendAs().list(
             userId='me'
     ).execute().get('sendAs')

Whether you’re using a Client Library (as our Python call) or using HTTP directly with GET https://www.googleapis.com/gmail/v1/users/userId/settings/sendAs, this is the payload you get back from the API:

     {
       "sendAs": [{
         "sendAsEmail": string,
         "displayName": string,
         "replyToAddress": string,
         "signature": string,
         "isPrimary": boolean,
         "isDefault": boolean,
         "treatAsAlias": boolean,
         "smtpMsa": {
           "host": string,
           "port": integer,
           "username": string,
           "password": string,
           "securityMode": string
         },
         "verificationStatus": string
       }, ...]
     }

The sendAs array gives you everything you need to know about each of your sender addresses. Did you know you can change a user’s email signature using the Gmail API without all of the data from above? You only need one field, or at most two: sendAsEmail and perhaps the isPrimary flag. By specifying a field mask with just those names from the sendAs attribute, you can cut out all those unneeded fields. Check it out here in Python with the field mask bolded for emphasis (versus the sample code above that doesn’t filter):

     addresses = GMAIL.users().settings().sendAs().list(
             userId='me', fields='sendAs(sendAsEmail,isPrimary)'
     ).execute().get('sendAs')

Field masks filter our unnecessary data from Google API call responses.

In part two of this video series (coming soon), we’ll show you a different use case for field masks...for update API calls. We’ll also provide some usage tips and demonstrate how field masks can be used in both read and update calls, how both types of calls are discrete, and how in some cases, you may use both as part of a single API call. Stay tuned!

To learn more about using field masks for partial response in API payloads, check out this section of the Client Library docs. For one of the most comprehensive write-ups on both (read and update) use cases, see the guide in the Google Slides API documentation.

A new issue tracker for G Suite developers

2017-03-30T11:30:00.000-07:00

Posted by Ryan Roth, Developer Programs Engineer and Wesley Chun, Developer Advocate, G Suite

You may have read recently that the Google Cloud Platform team upgraded to Issue Tracker, the same system that Google uses internally. This allows for improved collaboration between all of us and all of you. Issues you file will have better exposure internally, and you get improved transparency in terms of seeing the issues we’re actively working on. Starting today, G Suite developers will also have a new issue tracker to which we’ve already migrated existing issues from previous systems. Whether it’s a bug that you’ve found, or if you wish to submit a favorite feature request, the new issue tracker is here for you. Heads up, you need to be logged in with your Google credentials to view or update issues in the tracker.

The new issue tracker for G Suite developers.

Each G Suite API and developer tool has its own “component” number that you can search. For your convenience, below is the entire list. You may browse for issues relevant to the Google APIs that you’re using, or click on the convenience links to report an issue or request a new/missing feature:

To get started, take a look at the documentation pages, as well as the FAQ. For more details, be sure to check out the Google Cloud Platform announcement, too. We look forward to working more closely with all of you soon!

Bring the power of your apps into Gmail with Add-ons

2017-03-09T10:32:00.000-08:00

Posted by Thijs van As, Product Manager, Gmail

Few things are as satisfying as completing a task. But at work, it’s not always so easy. The days are short and packed with to-dos, like following up on sales leads, logging support tickets or sending invoices. And while great apps exists to tackle these workstreams, most users have to flip between them and their inbox because email is still “central command” for task management.
To solve this problem for users, today we're introducing the developer preview of Gmail Add-ons, a new way for G Suite users to access your app's functionality directly from Gmail in just one tap, no matter the device.

With Gmail Add-ons, developers can write an integration once and deploy it anywhere.

Save your users time

Add-ons provide a way to surface the functionality of your app or service when the context calls for it. They’re built on a powerful framework, which makes it easy for developers to trigger workflows based on email content. Say a Gmail user receives an email from a sales lead, and wants to add that contact to her CRM solution. With Gmail Add-ons, she can enter the contact’s required info and look up their account in that CRM system without leaving Gmail. No more tabbing, copying and pasting or sifting between mobile apps in order to get things done.

Write once, run anywhere

With Gmail Add-ons, developers only build their integration once, and it runs natively in Gmail on web, Android and iOS right away. Users only install the Add-on once, too, and it shows up in Gmail across their devices. So instead of wasting time writing separate integrations for web and mobile, you can focus on bringing your app’s most powerful features right to your users when they need them most. Gmail Add-ons are built in Apps Script using a newly-designed "Card" system that lets you easily combine different UI components. Developers can create a snappy user experience that feels like it was natively built into Gmail. The result: integrations that are cross-platform from the get-go that save your team time.

See what’s possible by signing up for the developer preview today

Gmail users will be able to install Add-ons via the G Suite Marketplace later this year, but that hasn’t stopped us from working with select partners to develop some amazing integrations to show what Add-ons are capable of.

No matter the task, Gmail users can easily find the right Add-on for the job. Here's how you could seamlessly use ProsperWorks and Intuit right from Gmail.

Intuit QuickBooks: The Intuit Add-on lets Gmail users and QuickBooks small business customers generate and send invoices and even confirm invoice status without ever leaving Gmail.
ProsperWorks: The ProsperWorks Add-on makes it easy for Gmail users to check the contact info of people on email threads against the information stored in their CRM.
Salesforce: The Salesforce Add-on allows Gmail users to look up existing contacts, add new ones, as well as associate email threads with one or more existing opportunities in Salesforce, right from the Gmail app.

The Salesforce Add-on makes it easy to capture background information from Gmail and tie it to a sales opportunity.

If you’re a developer, you can sign up for our Developer Preview today. We expect to start sending invitations for early developer access soon.

Building #withClassroom: stories of real schools using Classroom integrations

2017-03-02T12:28:00.000-08:00

By Lindsay Rumer, Product Marketing Manager, Google for Education

A few years ago, we launched the Classroom API to make it easier for developers to integrate their applications with Classroom, and for administrators to manage classes. Since then, hundreds of applications have integrated with Classroom to help teachers gamify their classes, improve students’ writing skills, build interactive presentations and more.

Using the API, developers can build deep integrations that manage Classroom rosters, assignments and grades. Or they can simply embed the Classroom share button to let users quickly share content. For teachers and students, these integrations create a seamless experience between Classroom and their favorite education apps.

Valuable integrations have been built to support the needs of teachers and students in the classroom that showcase the creative possibilities available through the Classroom API. Today, we take a look at how some schools are using Classroom integrations.

Enriching lessons with rich content from BrainPOP

In the words of Mike Jones, a teacher at Illinois State University’s K-8 Lab School, “Class time is precious. Why would I want to waste any of it with a process that can easily be automated?”

Improved automation is one of the key reasons we’ve seen education applications integrate with Google Classroom and one of those applications is BrainPOP. BrainPOP offers digital educational content that engages students through animated movies, learning games, quizzes, concept mapping, movie-making, and more.

The team at BrainPOP recognized that manually setting up individual student accounts for My BrainPOP could be a tedious task for teachers. Utilizing the Classroom API, the team at BrainPOP developed an integration that allows teachers to import their classes directly into My BrainPOP, automatically creating single sign-on-ready, student accounts and allowing students to log into BrainPOP through the Google launcher menu. According to Jones, the integration “allows all staff to easily access the benefits of BrainPOP and do what they do best: help children learn.”

Adjusting teaching tactics in real-time with Edulastic

Egg Harbor Township in New Jersey holds an intensive summer program for its Title I elementary students who aren’t ready to enter the next grade level. During last year’s program, the school had just 12 days to address learning gaps, which meant teachers had to stay laser-focused on deficiencies and adjust teaching tactics quickly to help their students achieve success. Given the tight timeframe, the school turned to Edulastic, an online assessment system that gives teachers instant teaching insights, and Google Classroom.

Edulastic’s Google Classroom sync meant the summer program could be set up quickly with no additional passwords or logins for teachers or students. As a result of the pilot, Egg Harbor Township Title I teachers used this integration beyond their summer program and the entire school subsequently decided to use it for their assessments as well.

Simplifying setup and syncing with Little SIS

Classroom integrations can also give IT leaders insights and administrative powers in Classroom. For instance, Little SIS for Classroom, an app designed and built by the team at Amplified Labs, is using the Classroom Courses and Guardians APIs to automate the setup and daily sync of Google Classroom classes, rosters, and guardian invites from information in the school’s SIS.

San Francisco Unified School District is piloting a roster-integrated approach to Google Classroom that they hope to scale to their 57,000 students. Executive Director of Technology & Innovation David Malone first approached Amplified Labs with guarded optimism because of the district’s size, but since installation he feels much more confident. “Despite being new to the market, I am really impressed at the maturity and thoughtfulness of the Little SIS app. It loaded our entire district’s G Suite users and 7,500 Classroom classes in just a few minutes, and allowed us to get a great baseline on the current state of adoption.”

We’ve been thrilled to see what developers have created using the Classroom API capabilities and the impact that it's had on teachers, students and administrators. If you’re interested in learning more about the Classroom API, check out developers.google.com/classroom or search for google-classroom on Stack Overflow. You can also join our announcement list to keep up with updates to our API.

Adding text and shapes with the Google Slides API

2017-02-23T11:12:00.001-08:00

Posted by Wesley Chun (@wescpy), Developer Advocate, G Suite

When the Google Slidesteam launched their very first API last November, it immediately opened up a whole new class of applications. These applications have the ability to interact with the Slides service, so you can perform operations on presentations programmatically. Since its launch, we've published several videos to help you realize some of those possibilities, showing you how to:

Today, we're releasing the latest Slides API tutorial in our video series. This one goes back to basics a bit: adding text to presentations. But we also discuss shapes—not only adding shapes to slides, but also adding text within shapes. Most importantly, we cover one best practice when using the API: create your own object IDs. By doing this, developers can execute more requests while minimizing API calls.

Developers use insertText requests to tell the API to add text to slides. This is true whether you're adding text to a textbox, a shape or table cell. Similar to the Google Sheets API, all requests are made as JSON payloads sent to the API's batchUpdate() method. Here's the JavaScript for inserting text in some object (objectID) on a slide:

{
    "insertText": {
        "objectId": objectID,
        "text": "Hello World!\n"
}

Adding shapes is a bit more challenging, as you can see from itssample JSON structure:

{
"createShape": {
        "shapeType": "SMILEY_FACE",
        "elementProperties": {
            "pageObjectId": slideID,
            "size": {
                "height": {
                    "magnitude": 3000000,
                    "unit": "EMU"
                },
                "width": {
                    "magnitude": 3000000,
                    "unit": "EMU"
                }
            },
            "transform": {
                "unit": "EMU",
                "scaleX": 1.3449,
                "scaleY": 1.3031,
                "translateX": 4671925,
                "translateY": 450150
            }
        }
    }
}

Placing or manipulating shapes or images on slides requires more information so the cloud service can properly render these objects. Be aware that it does involve some math, as you can see from the Page Elements page in the docs as well as the Transforms concept guide. In the video, I drop a few hints and good practices so you don't have to start from scratch.

Regardless of how complex your requests are, if you have at least one, say in an array named requests, you'd make an API call with the aforementioned batchUpdate() method, which in Python looks like this (assuming SLIDES is the service endpoint and a presentation ID of deckID):

SLIDES.presentations().batchUpdate(presentationId=deckID,
        body=requests).execute()

For a detailed look at the complete code sample featured in the DevByte, check out the deep dive post. As you can see, adding text is fairly straightforward. If you want to learn how to format and style that text, check out the Formatting Text post and video as well as the text concepts guide.
To learn how to perform text search-and-replace, say to replace placeholders in a template deck, check out the Replacing Text & Images post and video as well as the merging data into slides guide. We hope these developer resources help you create that next great app that automates the task of producing presentations for your users!

G Suite Developer Sessions at Google Cloud Next 2017

2017-02-08T10:14:00.001-08:00

Posted by Wesley Chun (@wescpy), Developer Advocate, G Suite

There are over 200 sessions happening next month at Google Cloud's Next 2017 conferencein San Francisco... so many choices! Along with content geared towards Google Cloud Platform, this year features the addition of G Suite so all 3 pillars of cloud computing (IaaS, PaaS, SaaS) are represented!

There are already thousands of developers including Independent Software Vendors (ISVs) creating solutions to help schools and enterprises running the G Suite collaboration and productivity suite (formerly Google Apps). If you're thinking about becoming one, consider building applications that extend, enhance, and integrate G Suite apps and data with other mission critical systems to help businesses and educational institutions succeed.

Looking for inspiration? Here's a preview of some of the sessions that current and potential G Suite developers should consider:

The first is "Automating internal processes using Apps Script and APIs for Docs editors." Not only will you hear directly from senior engineers on the Google Sheets & Google Slides REST API teams, but you'll also find out how existing customers are already doing so! Can't wait to get started with these APIs? Here are the intro blog post & video for the latest Google Sheets API as well as the intro blog post & video for the Google Slides API. Part of the talk also covers Google Apps Script, the Javascript-in-the-cloud solution that gives developers programmatic access to authorized G Suite data along with the ability to connect to other Google and external services.

If that's not enough Apps Script for you, or you're new to that technology, swing by to hear its Product Manager give you an introduction in his talk, "Using Google Apps Script to automate G Suite." If you haven't heard of Apps Script before, you'll be wondering why you haven't until now! If you want a headstart, here's a quick intro video to give you an idea of what you can do with it!

Did you know that Apps Script also powers "add-ons" which extend the functionality of Google Docs, Sheets, and Forms? Then come to "Building G Suite add-ons with Google Apps Script". Learn how you can leverage the power of Apps Script to build custom add-ons for your business, or monetize by making them available in the G Suite Marketplace where administrators or employees can install your add-ons for their organizations.

In addition to Apps Script apps, all your Google Docs, Sheets, and Slides documents live in Google Drive. But did you know that Drive is not just for individual file storage? Hear directly from a Drive Product Manager on how you can, "Building enterprise-ready apps with Team Drives API." With the Drive API and Team Drives, you can extend what Drive can do for your organization. One example from the most recent Google I/O tells the story of how WhatsApp used the Drive API to back up all your conversations! To get started with your own Drive API integration, check out this blog post and short video. Confused by when you should use Google Drive or Google Cloud Storage? I've got an app, err video, for that too! :-)

Not a software engineer but still code as part of your profession? Want to build a custom app for your department or line of business without having to worry about IT overhead? You may have heard about Google App Maker, our low-code development tool that does exactly that. Curious to learn more about it? Hear directly from its Product Manager lead in his talk entitled, "Building powerful custom apps fast with App Maker on G Suite."

All of these talks are just waiting for you at Next, the best place to get your feet wet developing for G Suite, and of course, the Google Cloud Platform. Start by checking out the session schedule. Next will also offer many opportunities to meet and interact with industry peers along with representatives from all over Google who love the cloud. Register today and see you in San Francisco!

Enhancements to coursework in the Classroom API

2017-01-11T09:27:00.000-08:00

Posted by Greg Zecchini, Google Classroom Software Engineer

Hundreds of education developers use the Classroom API to integrate their applications with Google Classroom. Last year, we announcedthe ability for external applications to read and write assignments. We've received a lot of feedback from developers who began integrating assignments with Classroom, and they said that they wanted to do even more.
Today, we're making the coursework endpoints more robust, with additional management capabilities. Applications can now:

Create and update questions
Modify and delete coursework
Add Drive items and YouTube videos to coursework and student submissions

Flat Education, a collaborative music notation app, already integrates with Classroom to let teachers quickly synchronize rosters and assignments, and design music activities accessible to students with just one click from Google Classroom. Flat has been piloting the new API functionality to create a more seamless integration. Flat CTO Vincent Giersch notes, "the support of Google Drive in the Google Classroom API is simply great: all the music scores created with G Suite for Education accounts on Flat being already Drive files, we can now directly add our Drive files in the assignments and students submissions. This will make possible for teachers and students to use Google Classroom with Flat as they would do with Google Docs."

In case you missed it, we've also made other recent updates to managing parents and guardians with the API. Classroom sends daily or weekly email summaries to guardians, and applications using the API to manage guardians can now detect if guardian visibility is enabled for a course, and list all guardians and guardian invitations in a domain.

For more details on what you can build with coursework, review the documentation, the FAQ, and ask questions on Stack Overflow. As always, let us know what you're building using the #withClassroom hashtag on Twitter or Google+. We look forward to working together to make it even easier for teachers and students to use the tools they love with Classroom.

Formatting text with the Google Slides API

2016-12-14T10:16:00.002-08:00

Posted by Wesley Chun (@wescpy), Developer Advocate, G Suite

It's common knowledge that presentations utilize a set of images to impart ideas to the audience. As a result, one of the best practices for creating great slide decks is to minimize the overall amount of text. It means that if you do have text in a presentation, the (few) words you use must have higher impact and be visually appealing. This is even more true when the slides are generated by a software application, say using the Google Slides API, rather than being crafted by hand.

The G Suite team recently launched the first Slides API, opening up a whole new category of applications. Since then, we've published several videos to help you realize some of those possibilities, showing you how to replace text and images in slides as well as how to generate slides from spreadsheet data. To round out this trifecta of key API use cases, we're adding text formatting to the conversation.

Developers manipulate text in Google Slides by sending API requests. Similar to the Google Sheets API, these requests come in the form of JSON payloads sent to the API's batchUpdate() method. Here's the JavaScript for inserting text in some shape (shapeID) on a slide:

{
    "insertText": {
        "objectId": shapeID,
        "text": "Hello World!\n"
}

In the video, developers learn that writing text, such as the request above, is less complex than reading or formatting because both the latter require developers to know how text on a slide is structured. Notice for writing that just the copy, and optionally an index, are all that's required. (That index defaults to zero if not provided.)

Assuming "Hello World!" has been successfully inserted in a shape on a slide, a request to bold just the "Hello" looks like this:

{
    "updateTextStyle": {
        "objectId": shapeID,
        "style": {
            "bold": true
        },
        "textRange": {
            "type": "FIXED_RANGE",
            "startIndex": 0,
            "endIndex": 5
        },
        "fields": "bold"
}

If you've got at least one request, like the ones above, in an array named requests, you'd ask the API to execute them with just one call to the API, which in Python looks like this (assuming SLIDES is your service endpoint and the slide deck ID is deckID):

SLIDES.presentations().batchUpdate(presentationId=deckID,
        body=requests).execute()

To better understand text structure & styling in Google Slides, check out the text concepts guidein the documentation. For a detailed look at the complete code sample featured in the DevByte, check out the deep dive post. To see more samples for common API operations, take a look at this page. We hope the videos and all these developer resources help you create that next great app that automates producing highly impactful presentations for your users!

Modifying email signatures with the Gmail API

2016-12-07T11:32:00.000-08:00

Posted by Wesley Chun (@wescpy), Developer Advocate, G Suite

The Gmail API team introduced a new settings feature earlier this year, and today, we're going to explore some of that goodness, showing developers how to update Gmail user settings with the API.

Email continues to be a dominant form of communication, personally and professionally, and our email signature serves as both a lightweight introduction and a business card. It's also a way to slip-in a sprinkling of your personality. Wouldn't it be interesting if you could automatically change your signature whenever you wanted without using the Gmail settings interface every time? That is exactly what our latest video is all about.

If your app has already created a Gmail API service endpoint, say in a variable named GMAIL, and you have the YOUR_EMAIL email address whose signature should be changed as well as the text of the new signature, updating it via the API is as pretty straightforward, as illustrated by this Python call to the GMAIL.users().settings().sendAs().patch() method:

signature = {'signature': '"I heart cats."  ~anonymous'}
GMAIL.users().settings().sendAs().patch(userId='me',
        sendAsEmail=YOUR_EMAIL, body=signature).execute()

For more details about the code sample used in the requests above as well as in the video, check out the deepdive post. In addition to email signatures, other settings the API can modify include: filters, forwarding (addresses and auto-forwarding), IMAP and POP settings to control external email access, and the vacation responder. Be aware that while API access to most settings are available for any G Suite Gmail account, a few sensitive operations, such as modifying send-as aliases or forwarding, are restricted to users with domain-wide authority.

Developers interested in using the Gmail API to access email threads and messages instead of settings can check out this other video where we show developers how to search for threads with a minimum number of messages, say to look for the most discussed topics from a mailing list. Regardless of your use-case, you can find out more about the Gmail API in the developer documentation. If you're new to the API, we suggest you start with the overview page which can point you in the right direction!

Be sure to subscribe to the Google Developers channel and check out other episodes in the G Suite Dev Show video series.

Generating slides from spreadsheet data

2016-11-30T10:26:00.003-08:00

Posted by Wesley Chun (@wescpy), Developer Advocate, G Suite

The G Suite team recently launched the very first Google Slides API, opening up a whole new set of possibilities, including leveraging data already sitting in a spreadsheet or database, and programmatically generating slide decks or slide content based on that data. Why is this a big deal? One of the key advantages of slide decks is that they can take database or spreadsheet data and make it more presentable for human consumption. This is useful when the need arises to communicate the information reflected by that data to management or potential customers.

Walking developers through a short application demonstrating both the Sheets and Slides APIs to make this happen is the topic of today's DevByte video. The sample app starts by reading all the necessary data from the spreadsheet using the Sheets API. The Slides API takes over from there, creating new slides for the data, then populating those slides with the Sheets data.

Developers interact with Slides by sending API requests. Similar to the Google Sheets API, these requests come in the form of JSON payloads. You create an array like in the JavaScript pseudocode below featuring requests to create a cell table on a slide and import a chart from a Sheet:

var requests = [

{"createTable": {

"elementProperties":

{"pageObjectId": slideID},

"rows": 8,

"columns": 4

}},

{"createSheetsChart": {

"spreadsheetId": sheetID,

"chartId": chartID,

"linkingMode": "LINKED",

"elementProperties": {

"pageObjectId": slideID,

"size": {

"height": { ... },

"width": { ... }

"transform": { ... }

}

}}

];
If you've got at least one request, say in a variable named requests (as above), including the Sheet's sheetID and chartID plus the presentation page's slideID. You'd then pass it to the API with just one call to the presentations().batchUpdate() command, which in Python looks like the below if SLIDES is your API service endpoint:

SLIDES.presentations().batchUpdate(presentationId=slideID,

body=requests).execute()

Creating tables is fairly straightforward. Creating charts has some magical features, one of those being the linkingMode. A value of "LINKED" means that if the Sheet data changes (altering the chart in the Sheet), the same chart in a slide presentation can be refreshed to match the latest image, either by the API or in the Slides user interface! You can also request a plain old static image that doesn't change with the data by selecting a value of "NOT_LINKED_IMAGE" for linkingMode. More on this can be found in the documentationon creating charts, and check out the video where you'll see both those API requests in action.

For a detailed look at the complete code sample featured in the video, check out the deep dive post. We look forward to seeing the interesting integrations you build with the power of both APIs!

Formatting cells with the Google Sheets API

2016-11-16T12:38:00.000-08:00

Posted by Wesley Chun (@wescpy), Developer Advocate, G Suite
At Google I/O earlier this year, we launched a new Google Sheets API (click here to watch the entire announcement). The updated API includes many new features that weren't available in previous versions, including access to more functionality found in the Sheets desktop and mobile user interfaces. Formatting cells in Sheets is one example of something that wasn't possible with previous versions of the API and is the subject of today's DevByte video. In our previous Sheets API video, we demonstrated how to get data into and out of a Google Sheet programmatically, walking through a simple script that reads rows out of a relational database and transferring the data to a new Google Sheet. The Sheet created using the code from that video is where we pick up today.

Formatting spreadsheets is accomplished by creating a set of request commands in the form of JSON payloads, and sending them to the API. Here is a sample JavaScript Object made up of an array of requests (only one this time) to bold the first row of the default Sheet automatically created for you (whose ID is 0):

{"requests": [
    {"repeatCell": {
        "range": {
            "sheetId": 0,
            "startRowIndex": 0,
            "endRowIndex": 1
        },
        "cell": {
            "userEnteredFormat": {
                "textFormat": {
                    "bold": true
                }
            }
        },
        "fields": "userEnteredFormat.textFormat.bold"
    }}
]}

With at least one request, say in a variable named requests and the ID of the sheet as SHEET_ID, you send them to the API via an HTTP POST to https://sheets.googleapis.com/v4/spreadsheets/{SHEET_ID}:batchUpdate, which in Python, would be a single call that looks like this:

SHEETS.spreadsheets().batchUpdate(spreadsheetId=SHEET_ID,
        body=requests).execute()

For more details on the code in the video, check out the deepdive blog post. As you can probably guess, the key challenge is in constructing the JSON payload to send to API calls—the common operations samples can really help you with this. You can also check out our JavaScript codelab where we guide you through writing a Node.js app that manages customer orders for a toy company, featuring the toy orders data we looked at today but in a relational database. While the resulting equivalent Sheet is featured prominently in today's video, we will revisit it again in an upcoming episode showing you how to generate slides with spreadsheet data using the new Google Slides API, so stay tuned for that!

We hope all these resources help developers enhance their next app using G Suite APIs! Please subscribe to our channel and tell us what topics you would like to see in other episodes of the G Suite Dev Show!

Introducing the Google Slides API

2016-11-09T10:30:00.000-08:00

Posted by Wesley Chun, Developer Advocate, G Suite
At Google I/O 2016, we gave developers a preview of the Google Slides API. Since then, the gears have been cranking at full speed, and we've been working with various early-access partners and developers to showcase what you can do with it. Today, we're happy to announce that the Slides API v1 is now generally available and represents the first time that developers have ever been able to programmatically access Slides!
The Slides API breaks new ground, changing the way that presentations are created. No longer do they require manual creation by users on their desktops or mobile devices. Business data on inventory items like retail merchandise, homes/property, hotels/lodging, restaurants/menus, venues/events, and other "cataloged" assets can be instantly turned into presentations based on pre-existing slide templates. Traditionally, the sheer amount of data (and of course time[!]) that went into creating these slide decks made it unwieldy if done by hand. Applications leveraging the API can easily generate presentations like these, customized as desired, and in short order.
Developers use the API by crafting a JSON payload for each request. (We recommend you batch multiple commands together to send to the API.) You can think of these as actions one can perform from the Slides user interface but available programmatically. To give you an idea of how the new API works, here are what some requests look like for several common operations:

// create new slide (title & body layout)
{
    "createSlide": {
        "slideLayoutReference": {
            "predefinedLayout": "TITLE_AND_BODY"
        }
    }
},
// insert text into textbox
{
    "insertText": {
        "objectId": titleID,
        "text": "Hello World!"
    }
},
// add bullets to text paragraphs
{
    "createParagraphBullets": {
        "objectId": shapeID,
        "textRange": {
            "type": "ALL"
        }
    }
},
// replace text "variables" with image
{
    "replaceAllShapesWithImage": {
        "imageUrl": imageURL,
        "replaceMethod": "CENTER_INSIDE",
        "containsText": {
            "text": "{{COMPANY_LOGO}}"
        }
    }
}

If you're interested in seeing what developers have already built using the API, take a look at our initial set of partner integrations by Conga, Trello, Lucidchart, Zapier and more, as described in detail in our G Suite blog post.

To help you get started, check out the DevByte above from our new series dedicated to G Suite developers. In the video, we demonstrate how to take "variables" or placeholders in a template deck and use the API to generate new decks replacing those proxies with the desired text or image. Want to dive deeper into its code sample? Check out this blogpost. If you're not a Python developer, it'll be your pseudocode as you can use any language supported by the Google APIs Client Libraries. Regardless of your development environment, you can use similar "scaffolding" to generate many presentations with varying content for your users. Stay tuned for more videos that highlight other Slides API features.
The Slides API is available to projects in your Google Developers console today. Developers can find out more in the official documentation which features an API overview plus Quickstarts, sample code in multiple languages and environments, to bootstrap your next project. We look forward to seeing all the amazing slide deck generating applications you build with our first ever API!

Peeking into the future of work with Salesforce

2016-10-13T14:32:00.001-07:00

Posted by Tom Holman, Product Manager, Google Sheets

Originally posted to Google Cloud

When it comes to redefining how people go about their everyday work, Google and Salesforce have shared a remarkably similar path, with our roots planted firmly in the cloud.

That's why we were very excited to share the stage last week at Dreamforce to showcase two integrations that Salesforce built on top of G Suite: Salesforce Lightning for Gmail and Sales Cloud integration with Google Sheets. In addition to existing integrations with Google Calendar, Gmail (for Salesforce IQ), Drive and Contacts, these new offerings will go a long way in helping people work effectively with smarter tools.

Salesforce Lightning for Gmail

Salesforce Lightning for Gmail

At Dreamforce, we showcased the upcoming Lightning for Gmail integration, which brings together our leading CRM and email services.

With this integration, sales reps can now streamline repetitive but important tasks: they can review Salesforce records relevant to their emails, add contacts from their address book into Salesforce, and even create new Salesforce records, all from within Gmail.

A pilot of Lightning for Gmail will be available by the end of this year for free to all Salesforce customers. Interested customers can contact their Salesforce account managers to sign up for the pilot program.

Sales Cloud and Google Sheets

Link any Sales Cloud List View to a source Google Sheet, and view, edit, and delete that data directly.

The Sales Cloud integration with Sheets, meanwhile, makes it easy for sales reps to link any Salesforce List View to a Google Sheet. Users can also view, edit, and delete records within Sheets and sync those changes back to Salesforce. Better still, the integration also supports your business logic and validation rules.

We gave a joint preview of the Sales Cloud and Google Sheets integration at Google I/O this summer, and today are happy to announce that it will be available in beta to all Sales Cloud customers by the end of this year.

We had a blast working with the Salesforce team to bring these new solutions to life.