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 guide in 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!

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.

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:

];
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:
       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 documentation on 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!

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!

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!

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

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

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.

Posted by Michael Winser, Product Lead, Google Apps and Wesley Chun, Developer Advocate, Google Apps

Last week, we clarified the expectations and responsibilities when accessing Google user data via OAuth 2.0. Today, we’re announcing that in order to better protect users, we are increasing account security for enterprise Gmail users effective October 5, 2016. At this time, a new policy will take effect whereby users in a Google Apps domain, while changing their passwords on or after this date, will result in the revocation of the OAuth 2.0 tokens of apps that access their mailboxes using Gmail-based authorization scopes. Please note that users will not notice any specific changes on this date and their applications will continue to work. It is only when a user changes their password from that point moving forward that their Gmail-related tokens become invalid.

Developers should modify their applications to handle HTTP 400 or 401 error codes resulting from revoked tokens and prompt their users to go through the OAuth flow again to re-authorize those apps, such that they can access the user’s mailbox again (additional details below). Late last year, we announced a similar, planned change to our security policy that impacted a broader set of authorization scopes. We later decided not to move forward with that change for Apps customers and began working on a less impactful update as described above.

What is a revoked token?

A revoked OAuth 2.0 token no longer provides access to a user’s resources. Any attempt to use a revoked token in API calls will result in an error. Any existing token strings will no longer have any value and should be discarded. Applications accessing Google APIs should be modified to handle failed API calls.

Token revocation itself is not a new feature. Users have always been able to revoke access to applications in Security Checkup, and Google Apps admins have the ability to do the same in the Admin console. In addition, tokens that were not used for extended periods of time have always been subject to expiration or revocation. This change in our security policy will likely increase the rate of revoked tokens that applications see, since in some cases the process will now take place automatically.

What APIs and scopes are impacted?

To achieve the security benefits of this policy change with minimal admin confusion and end-user disruption, we’ve decided to limit its application to mail scopes only and to exclude Apps Script tokens. Apps installed via the Google Apps Marketplace are also not subject to the token revocation. Once this change is in effect, third-party mail apps like Apple Mail and Thunderbird―as well as other applications that use multiple scopes that include at least one mail scope―will stop accessing data upon password reset until a new OAuth 2.0 token has been granted. Your application will need to detect this scenario, notify the user that your application has lost access to their account data, and prompt them to go through the OAuth 2.0 flow again.

Mobile mail applications are also included in this policy change. For example, users who use the native mail application on iOS will have to re-authorize with their Google account credentials when their password has been changed. This new behavior for third-party mail apps on mobile aligns with the current behavior of the Gmail apps on iOS and Android, which also require re-authorization upon password reset.

How can I determine if my token was revoked?

Both short-lived access tokens and long-lived refresh tokens will be revoked when a user changes their password. Using a revoked access token to access an API or to generate a new access token will result in either HTTP 400 or 401 errors. If your application uses a library to access the API or handle the OAuth flow, then these errors will likely be thrown as exceptions. Consult the library’s documentation for information on how to catch these exceptions. NOTE: because HTTP 400 errors may be caused by a variety of reasons, expect the payload from a 400 due to a revoked token to be similar to the following:

{
  "error_description": "Token has been revoked.", 
  "error": "invalid_grant"
}

How should my application handle revoked tokens?

This change emphasizes that token revocation should be considered a normal condition, not an error scenario. Your application should expect and detect the condition, and your UI should be optimized for restoring tokens.

To ensure that your application works correctly, we recommend doing the following:

• Add error handling code around API calls and token refreshes that can detect revoked tokens.
• Upon detecting a revoked token, disable any application features that rely on Google API access until the user can re-authorize your application. For example, suspend any recurring background jobs that sync data with a Google API which may be affected.
• Notify the user that access has been revoked and prompt them to re-authorize access to their resources.
  • If your app interacts directly with the user, you will need to prompt the user to re-authorize, i.e., send an email to the user and/or show them an alert the next time they open your application.
  • However, if your app runs independently of the user, say a background app that uses the Gmail API, you'll need to notify the user through email or some other mechanism.
  • Provide a streamlined UI for re-authorizing access. Avoid having users navigate through your application to find the original setting.
  • Note that revoked tokens will result in similar error messages regardless of how the token was revoked. Your messaging should not assume that the token was revoked due to a password change.

If your application uses incremental authorization to accrue multiple scopes in the same token, you should track which features and scopes a given user has enabled. The end result is that if your app requested and obtained authorization for multiple scopes, and at least one of them is a mail scope, that token will be revoked, meaning you will need to prompt your user to re-authorize for all scopes originally granted.

Many applications use tokens to perform background or server-to-server API calls. Users expect this background activity to continue reliably. Since this policy change also affects those apps, this makes prompt notification requesting re-authorization even more important.

What is the timeline for this change?

To summarize, properly configured applications should be expected to handle invalid tokens in general, whether they be from expiration, non-existence, and revocation as normal conditions. We encourage developers to make any necessary changes to give their users the best experience possible. The policy change is planned to take effect on October 5, 2016.

Please see this Help Center article and FAQ for more details and the full list of mail scopes. Moving forward, any additional scopes to be added to the policy will be communicated in advance. We will provide those details as they become available.

Posted by William Denniss, Product Manager, Identity and Authentication
Lavanya Mahendran, Policy Advisor, Google Cloud Platform and Google APIs

Developers have created an exciting ecosystem of mobile and web applications that offer a seemingly infinite array of features and services for consumers to utilize. Today you can download applications that offer to increase your productivity at work, as well as applications that manage your daily expenses or help you meditate, and many more.

We know that our users love using these applications, and we recognize that often Google users want to share their data with these applications to personalize or enhance the experience. Google provides a rich variety of API services that developers may access, and we provide developers the ability to request permission directly from our users when they want to access various categories of user data.

The privacy and security of our users’ data is very important to us, and we’ve always expected developers to treat Google user data with transparency and concern for user choice. Among other things, this means that we’ve long expected developers to get informed consent when they request access to user data, so that users understand what data they are sharing and how it will be used.

We’re always looking for ways to make our requirements more accessible to everyone, including our end-users. To that end, we recently published expanded policy guidelines for developers who wish to access Google user data using our API services. We hope this guidance will help developers and Google users interact in a manner that is informed and overall consistent with user expectations.

Read the full Google API Services User Data policy.

We hope that developers and Google users find this policy guidance helpful. We believe that transparency around the collection and use of Google user data is necessary to ensure informed user consent, but also that it genuinely fosters a helpful and productive dialogue between developers and users that ultimately benefits the entire ecosystem. Google account users can review and manage the apps and websites connected to their Google account from the My Account page.

Posted by Pierce Vollucci, Associate Product Manager, Gmail and Steve Bazyl, Developer Programs Engineer, Google Apps

When you send emails, your recipients might read them on a computer, tablet, or phone—or more likely, all three. However your message might look different on all these devices. Later this month, you’ll be able to use CSS media queries with Gmail and Inbox by Gmail to ensure that your message is formatted the way you intended, whether it's viewed on a computer, a phone in portrait mode, or a tablet in landscape mode. You’ll be able to change styles based on width, rotation, and resolution, allowing for more responsive formatting to optimize your email for every device.

Example of an email before and after responsive design

In discussions with email designers, these supported CSS rules were identified as the most useful media queries to support responsive design. This is just one part of an overall effort to expand CSS support in Gmail and to give email designers more control over how their messages are rendered. For example, the CSS below applies the color red when the screen width exceeds 500px.

@media screen and (min-width: 500px) {
  .colored {
    color:red;
  }
}

You can find the full list of supported CSS rules in the developer documentation. We hope this reference helps you create more feature-rich, responsive email for users. Happy formatting!

Google Calendar and Google Drive for Atlassian HipChat

Guest post by Rich Manalang, Partner Engineering Lead at Atlassian. Posted by Wesley Chun, Developer Advocate, Google Apps.

Atlassian has been building collaboration software for over 14 years. With products that include JIRA, Confluence, Bitbucket, and HipChat, our organization has learned a lot about how teams work effectively.

HipChat launched the Connect API in November 2015, and since then we’ve continued to build upon our ecosystem of integrations and collaborations. A few months ago, our team looked at potential integrations that would be a perfect marriage with HipChat — and today, we’re excited to share the Google Calendar and Google Drive integration for HipChat.

Millions of people use Google’s products everyday, so we instantly knew this was the right opportunity. Many of HipChat’s customers are developers, and they told us that managing time and better access to files were two of the most important things in their day-to-day. Now with Google integrations available inside of HipChat, there’s no need to launch another browser tab or app.

By building Google Calendar directly into HipChat, we’re improving the signal-to-noise ratio on a daily basis. Before this integration, we all dealt with context-switching between apps and browser tabs. Now, customers can use HipChat to view and share various calendars, schedules and important dates in the right sidebar. Our customers spend their entire working day inside our HipChat app — unlike email, you don’t just fire it up and quit periodically. So naturally, having your calendar up-front is compelling. And what’s more, you can slice and dice which ones you see on a per-room basis. Say you’re a program manager — if you go into the Engineering HipChat “room,” you can see the Engineering and related calendars. Then, when you switch into the Marketing room, you may see different calendars depending on whom you’re collaborating with.

Having dual calendars front and center within HipChat is critical for staying on top of my work. I’m personally very excited about the Google Calendar integration because it’s one of the most important apps I use day-in and day-out. As a single parent with two kids busy at school, I need to know everything that's going on. My calendar is stacked, and I want to see it all at a glance. That urgency is similar when considering the most important documents in someone's daily workflow.

When we started working on the Google Drive integration, we wanted to focus on what was most important — accessibility, shareability, and ease of use.

There are many benefits to bringing third party integrations right into HipChat. The Google Drive integration allows teams to collaborate and work together while saving time and eliminating context switching. Being able to access documents, presentations, and files is critical whether a user is at the office or remote. It integrates nicely into the right side bar, enabling users to access, share to the room, and collaborate around important documents, presentations, and spreadsheets. We worked with third party developer Topdox, who was a tremendous partner in bringing this new feature into HipChat. We’re getting great feedback around the speed and simplicity of sharing files without ever having to leave the HipChat application.

Why would Google Developers be interested?

When we built these integrations, we wanted to give our users a nice balance between out-of-the-box usefulness but also ultimate flexibility in which calendars and accounts a user can view. To do that, we wanted one UI that can display multiple calendars from multiple Google accounts — similar to what most Calendar mobile apps do today, including Google’s own mobile Calendar app.

These new integrations were built entirely on top of Google’s API. Google’s Calendar API is a full featured API that gave us everything we needed to create a calendar experience fit for HipChat’s users. On top of that, the API was designed with efficiency in mind with push notifications for changes to resources and incremental syncing to improve performance and bandwidth use.

Building on top of Google APIs has allowed us to think of new ways to bring even tighter integrations with our products along with the myriad of add-ons built by Atlassian’s ecosystem. One idea under consideration is to link JIRA Software and Google Calendar so that all your JIRA issues are overlayed onto a Google Calendar. Then this calendar can be shared with the relevant HipChat room bringing it all together and enabling teams to get more done. We’d love to hear your feedback on this idea.

We think there are many opportunities to improve how teams work together by integrating with Google and Atlassian. You can find out more about Atlassian Connect on our developer’s site and the Google APIs on theirs.

Posted by Chris Han, Product Manager, Apps Developer Platform

For over 6 years, the Google Apps Marketplace has been the #1 destination for administrators and business users within Google Apps domains to find, discover and install third-party apps and integrations that extend what they can do with Google Apps.

We are happy to announce that over the next few weeks, we are opening up the Google Apps Marketplace to consumer end-users, and wanted to give you a heads up as well as some technical guidance should you wish to make any changes or tweaks to your app. Here is what you need to know if you are a technology partner or developer building for the Google Apps Marketplace:

First, this change only applies to apps which have opted in to “Enable Individual Install” on the Google Apps Marketplace SDK located in the Developer Console. Apps not enabled with individual install will not appear to consumers, nor will they be installable for them.

Second, as a general best practice, we recommend that you do not use a user’s email address as a unique identifier. Email addresses for both consumer and business accounts can be renamed or changed. Make sure to always use the Google Account ID. For more information on sign in and security, please read this.

If you have questions or have any feedback regarding this development, please let us know here. We look forward to exposing what you’ve built to our broader community.

Posted by Shashank Gupta, Product Manager, Google Apps for Work and Wesley Chun, Developer Advocate, Google Apps
Back in 2013, we launched the Google Apps Admin SDK, and later announced as a result that several outdated Apps Admin APIs would be deprecated and shut down in April 2015. Today, we are continuing this effort of removing older, less-used functionality by announcing the deprecation of the GData Admin Settings API. Some GData API functionality will find a replacement from an Admin SDK counterpart, while other features will be discontinued. The following table summarizes which features will be retained (and where to access replacement functionality) and which won’t:

Admin Settings API	Endpoint	Post-Deprecation Replacement (if any)
General Settings	/defaultLanguage	Directory API: Customers
	/organizationName	Directory API: Customers
	/currentNumberOfUsers	no replacement / discontinued
	/maximumNumberOfUsers	no replacement / discontinued
Account Settings	/accountInformation/supportPIN	no replacement / discontinued
	/accountInformation/customerPIN	no replacement / discontinued
	/accountInformation/adminSecondaryEmail	Directory API: Customers
	/accountInformation/edition	no replacement / discontinued
	/accountInformation/creationTime	Directory API: Customers
	/accountInformation/countryCode	Directory API: Customers
Appearance Settings	All endpoints	no replacement / discontinued
Verification Settings	All endpoints	no replacement / discontinued
Single Sign-on (SSO) Settings	All endpoints	replacement API coming before Aug 2017
Gateway and Routing Settings	All endpoints	no replacement / discontinued

To summarize, the GData Admin Settings API is being deprecated today and will remain operational for until October 31, 2018, to give developers time to migrate. This means that on October 31, 2018, this deprecated API will be shut down.

Posted by Tom Holman, Product Manager, Google Sheets and Josh Danziger, Software Engineer, Google Sheets

At Google, we are always working to keep our users' information safe. As part of these ongoing efforts, we will begin requiring explicit authorization when third-party sites request access to Google Sheets content via the Google Visualization API or Google Query Language.

For many developers, this change will be transparent, but others may need to make changes in order to continue reading spreadsheet data. For more details on the technical changes required, please visit the Google Charts API Documentation. We will begin enforcing these requirements on September 14, 2016.

If you have any questions or concerns about this change, please follow up in the Google Docs forum or on Stack Overflow.

Calling all developers: try our developer preview today!

As you can see from above, Android add-ons offer a great opportunity to build innovative integrations and reach Docs and Sheets users around the world. They’re basically Android apps that connect with Google Apps Script projects on the server-side, allowing them to access and manipulate data from Google Docs or Sheets using standard Apps Script techniques. Check out our documentation which includes UI guidelines as well as sample code to get you started. We’ve also made it easy for you to publish your apps with the Apps Script editor.

Android add-ons are available today as a developer preview. We look forward to seeing what you build!

Posted by Hodie Meyers, Product Manager, Google Drive and Steve Bazyl, Developer Programs Engineer, Google Apps

Last year, we announced the deprecation of Google Drive web hosting for users and developers, and that the service will be shut down on August 31, 2016. We’d like to remind remaining users that websites hosted via googledrive.com/host/[id] will become unavailable from that date.

For those who haven’t switched yet, please consider the following alternatives.

• Google Drive API: If you’re using the web hosting feature to provide logged-in users access to public Drive items, you can use the API instead.
• Firebase Hosting: If you’re using the web hosting feature to provide users access to static web pages whose content lives on Drive, you can migrate to Firebase by uploading the content to Firebase and serving pages via Firebase-specific URLs. Please see this video to learn more!
• Google Cloud Platform: If you’re already a Google Cloud Platform customer, we recommend migrating to Google Cloud Platform static-website hosting.

Posted by Brandon Jewett-Hall, Software Engineer, Gmail and Wesley Chun, Developer Advocate, Google Apps

If you've been pining for a way to update your users' email signatures with a different inspirational quote each day or enable "Out of Office" auto-replies when their calendars are marked as busy, then you're in luck. Today, we're extending the Gmail API with new endpoints for managing settings. These new endpoints cover the following features:

• Filters
• Forwarding addresses and auto-forwarding
• IMAP and POP settings
• Send-as aliases
• Signatures
• Vacation responder

With this update, we're equipping developers with some new tools that have never been available in any previous Google API. These include the ability to:

• Retrieve and update signatures for send-as aliases
• Configure forwarding to external addresses
• Configure send-as aliases that send mail through external providers
• Use HTML in vacation messages
• Manipulate settings for gmail.com accounts

Over time we'll continue to expand the API with additional settings features such as support for managing mailbox delegates, so stay tuned for more announcements.

Get started now

Most of the settings endpoints are available for any Google Apps or Gmail account, but a few sensitive operations, such as modifying send-as aliases or forwarding, are restricted to service accounts with domain-wide authority. See the reference docs for more details and to get started.

What about the existing Email Settings API in the Admin SDK?

This update to the Gmail API effectively replaces the older Email Settings API, so we're also announcing its deprecation today and will turn it down fully on July 7, 2017. We've put together a migration guide to assist clients in porting their existing integrations over to their newer counterparts in the Gmail API. If you have any issues, check out the gmail-api tag on StackOverflow.

We look forward to seeing what you build with these new features in the Gmail API!

Posted by Wesley Chun (@wescpy), Developer Advocate, Google Apps

At Google I/O 2016, 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 functionality found in the Sheets desktop and mobile user interfaces. My latest DevByte video shows developers 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 brand new Google Sheet.

Let’s take a sneak peek of the code covered in the video. Assuming that SHEETS has been established as the API service endpoint, SHEET_ID is the ID of the Sheet to write to, and data is an array with all the database rows, this is the only call developers need to make to write that raw data into the Sheet:

SHEETS.spreadsheets().values().update(spreadsheetId=SHEET_ID,
    range='A1', body=data, valueInputOption='RAW').execute()

Reading rows out of a Sheet is even easier. With SHEETS and SHEET_ID again, this is all you need to read and display those rows:

rows = SHEETS.spreadsheets().values().get(spreadsheetId=SHEET_ID,
    range='Sheet1').execute().get('values', [])
for row in rows:
    print(row)

If you’re ready to get started, take a look at the Python or other quickstarts in a variety of languages before checking out the DevByte. If you want a deeper dive into the code covered in the video, check out the post at my Python blog. Once you get going with the API, one of the challenges developers face is in constructing the JSON payload to send in API calls—the common operations samples can really help you with this. Finally, if you’re ready to get going with a meatier example, check out our JavaScript codelab where you’ll write a sample Node.js app that manages customer orders for a toy company, the database of which is used in this DevByte, preparing you for the codelab.

We hope all these resources help developers create amazing applications and awesome tools with the new Google Sheets API! Please subscribe to our channel, give us your feedback below, and tell us what topics you would like to see in future episodes!

Posted by Wesley Chun (@wescpy), Developer Advocate, Google Apps

Google Forms has become a popular tool for polling colleagues or creating a pop quiz for students. Creating a few Forms manually may be manageable, but what if you needed to create hundreds or thousands? This is where Google Apps Script can help you scale, by giving you the ability to generate Google Forms programmatically. In this latest edition of the Launchpad Online developer video series, we focus on the JavaScript snippet below that shows you just how easy it is to automate the creation of Google Forms:

 function createForm() {  
   // create & name Form  
   var item = "Speaker Information Form";  
   var form = FormApp.create(item)  
       .setTitle(item);  
   
   // single line text field  
   item = "Name, Title, Organization";  
   form.addTextItem()  
       .setTitle(item)  
       .setRequired(true);  
   
   // multi-line "text area"  
   item = "Short biography (4-6 sentences)";  
   form.addParagraphTextItem()  
       .setTitle(item)  
       .setRequired(true);  
   
   // radiobuttons  
   item = "Handout format";  
   var choices = ["1-Pager", "Stapled", "Soft copy (PDF)", "none"];  
   form.addMultipleChoiceItem()  
       .setTitle(item)  
       .setChoiceValues(choices)  
       .setRequired(true);  
   
   // (multiple choice) checkboxes  
   item = "Microphone preference (if any)";  
   choices = ["wireless/lapel", "handheld", "podium/stand"];  
   form.addCheckboxItem()  
       .setTitle(item)  
       .setChoiceValues(choices);  
 }  

If you’re ready to get started, you can find more information, including another intro code sample, in the Google Forms reference section of the Apps Script docs. In the video, I challenge viewers to enhance the code snippet above to read in “forms data” from an outside source such as a Google Sheet, Google Doc, or even an external database (accessible via Apps Script’s JDBC Service) to generate multiple Forms with. What are other things you can do with Forms?

One example is illustrated by this Google Docs add-on I created for users to auto-generate Google Forms from a formatted Google Doc. If you’re looking to do integration with a variety of Google services, check out this advanced Forms quickstart that uses Google Sheets, Docs, Calendar, and Gmail! Finally, Apps Script also powers add-ons for Google Forms. To learn how to write those, check out this Forms add-on quickstart.

We hope the DevByte and all these examples inspire you to create awesome tools with Google Forms, and taking the manual creation burden off your shoulders! If you’re new to the Launchpad Online developer series, we share technical content aimed at novice Google developers, as well as discuss the latest tools and features to help you build your app. Please subscribe to our channel, give us your feedback below, and tell us what topics you would like to see in future episodes!

Originally posted on Google for Work blog

Originally posted on Google for Education blog

Posted by Ed Kupershlak, Google Classroom Software Engineer

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

Do more with coursework in the Classroom API

Today, we’re introducing new coursework endpoints that allow developers to access assignments, grades and workflow. Learning tools can focus on creating great content and, in turn, use Classroom to manage the workflow for assignments created with this content. Gradebooks and reporting systems can now also sync grades with Classroom, eliminating the need for teachers to manually transfer grades.

Several partners have been helping to test the new functionality, including:

• OpenEd, which provides a library of open education resources for K-12 teachers
• Tynker, a creative computing platform for teaching students to code
• GeoGebra, a visual mathematics platform that allows students and teachers to author interactive mathematics content

Access course Drive folders, groups and materials

In addition to the coursework endpoints, we’ve added new functionality to our existing course and roster API endpoints. Developers can now access course Drive folders, groups and materials. Applications can use this new functionality to store files in the same Drive folder as the rest of the resources in a class, or use course groups to manage file sharing permissions.

In the coming months, we’ll be adding more coursework management capabilities. When we do, we’ll post updates to the developer forum and issue tracker. We look forward to working together to make it even easier for teachers and students to use the tools they love with Classroom. Developers, please review the documentation, the FAQ, and ask questions on Stack Overflow. Also, don’t forget to let us know what you’re building using the #withClassroom hashtag on Twitter or G+. And teachers, check out this list of applications that work well with Classroom today.