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:
batchUpdate()
shapeID
{ "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" }
requests
SLIDES
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!
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:
GMAIL
YOUR_EMAIL
GMAIL.users().settings().sendAs().patch()
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.
// 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}}" } } }
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:
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.
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.
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:
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.
Posted by Mike Procopio, Engineering Manager, Google Drive and Wesley Chun, Developer Advocate, Google Apps
WhatsApp is one of the most popular mobile apps in the world. Over a billion users send and receive over 42 billion messages, photos, and videos every day. It's fast, easy to use, and reliable.
But what happens when people lose their phone or otherwise upgrade to a new one? All those messages and memories would be gone. So we worked with WhatsApp to give their users the ability to back up their data to Google Drive and restore it when they setup WhatsApp on a new phone. With messages and media safely stored in your Drive, there’s no more worry about losing any of those memories.
One of the biggest challenges for an integration of this scope is scaling. How do you back up data for a billion users? Many things were done to ensure the feature works as intended and is unnoticeable by users. Our approach? First, we relied on a proven infrastructure that can handle this kind of volume—Google Drive. Next, we optimized what to back up and when to do the backups—the key was to upload only incremental changes rather than transmit identical files.
On the server side (backend), we focused on optimizing byte storage as well as the number of network calls between WhatsApp and Google. As far as deployment goes, we rolled out slowly over several months to minimize the size and impact of deployment.
If you have ever used WhatsApp, you know how it gets out of your way, and lets you get started quickly: no account creation, no passwords to manage, and no user IDs to remember or exchange. This sets a high bar for any integration with WhatsApp: for it to feel like a natural part of WhatsApp, it has to be as seamless, fast, and reliable as WhatsApp itself.
By using the Google Drive API, we were able to achieve this: no need to type in any usernames or passwords, just a few taps in the app, and WhatsApp starts backing up. The best part is that all the tools used in the integration are available to all developers. With the Google Drive API, seamless and scalable integrations are as easy to use for the user as they are for developers.
To learn more about how we did it and get all the details, check out the complete talk we gave together with WhatsApp at Google I/O 2016.
Are you ready to integrate your web and mobile apps with Google Drive? Get started today by checking out our intro video as well as the video demoing the newest API, then dig in with the developer docs found at developers.google.com/drive. We're excited to see what you build next with the Drive API—and we're ready to scale with you!
Posted by Tom Holman, Product Manager, Google Sheets
There was a time when office work used to be all about pushing physical paper. Computing and productivity tools have made things better, but workers still find themselves doing the same tasks over and over across the different apps they use: copying and pasting from a CRM app to a slide presentation, or manually exporting data from a project management app just to turn around and import it back into a spreadsheet. It’s the digital equivalent of pushing paper.
To make it easier to get the job done across multiple apps, without all the copy and paste, we’re announcing three new APIs and a new feature to help workers get to the data they need, when and where they need it.
Build seamless integrations with the new Sheets and Slides APIs
Our new APIs let developers connect their apps—and the data within them—more deeply with Google Sheets and Google Slides.
The new Sheets API gives developers programmatic access to powerful features in the Sheets web and mobile interfaces, including charts and pivot tables. For example, developers can use Sheets as part of a rich workflow that pushes data from their app into Sheets and allows users to collaborate on that data before the updated data is pulled back into the original app, removing altogether the need to copy and paste.
Teams at Anaplan, Asana, Sage, Salesforce, and SAP Anywhere are already building interesting integrations with the new Sheets API. Check out the video below to see an overview of what’s possible as well as several example integrations.
Partner integrations with the new Google Sheets API
The new Sheets API is available today. Find the developer documentation as well as a codelab to help you get started at developers.google.com/sheets.
Similar to the Sheets API, the new Slides API gives developers programmatic access to create and update presentations. For example, developers can use this API to push data and charts into Slides to create a polished report from source data in other application, ready to present.
Conga, ProsperWorks, SalesforceIQ and Trello are all building integrations with Slides using the new API. Several examples of what’s possible are in the video below.
Partner integrations with the new Google Slides API
The Slides API will be launching in the coming months, and these partner integrations will be available soon after. You can sign up for early access to the Slides API at developers.google.com/slides.
Keep your data in sync with the new Classroom API
For developers building tools and workflows for schools, the Classroom API has launched new coursework endpoints to help you build stronger integrations that keep your data in sync. Read the full announcement on the Google for Education blog, here.
Sync assignments & grades programmatically with the Google Classroom API
Say goodbye to stale data with linked charts
Finally, to make sure we can help keep all this data flowing seamlessly from app to app, users can now also embed linked charts from Sheets into Docs or Slides. The result? Once the underlying data in a spreadsheet changes, whether that change comes from an action taken in another app via the API or a collaborator, an updated chart in the corresponding presentation or document is just one click away.
Linked charts allow for easy updates in Docs & Slides
For more information, see how to add a chart to a document or to a presentation.
We can't wait to see what you build.
Posted by Vartika Agarwal, Technical Program Manager, Identity & Authentication, and Wesley Chun, Developer Advocate, Google
As we indicated several years ago, we are moving away from the OAuth 1.0 protocol in order to focus our support on the current OAuth standard, OAuth 2.0, which increases security and reduces complexity for developers. OAuth 1.0 (3LO)1 was shut down on April 20, 2015. During this final phase, we will be shutting down OAuth 1.0 (2LO) on October 20, 2016. The easiest way to migrate to the new standard is to use OAuth 2.0 service accounts with domain-wide delegation.
If the migration for applications using these deprecated protocols is not completed before the deadline, those applications will experience an outage in their ability to connect with Google, possibly including the ability to sign-in, until the migration to a supported protocol occurs. To avoid any interruptions in service for your end-users, it is critical that you work to migrate your application(s) prior to the shutdown date.
With this step, we continue to move away from legacy authentication/authorization protocols, focusing our support on modern open standards that enhance the security of Google accounts and that are generally easier for developers to integrate with. If you have any technical questions about migrating your application, please post them to Stack Overflow under the tag google-oauth.
1 3LO stands for 3-legged OAuth: there's an end-user that provides consent. In contrast, 2-legged (2LO) doesn’t involve an end-user and corresponds to enterprise authorization scenarios such as enforcing organization-wide policy control access.
Posted by Posted by Wesley Chun (@wescpy), Developer Advocate, Google Apps
Seasons greetings! In case you missed it last week, the Google Drive team announced the release of the next version of their API. Today, we dig deeper into details about the release with developers. In the latest edition of the Launchpad Online developer video series, you'll get everything you need to know about the new release (v3), as well as its relationship with the previous version (v2).
This jam-packed episode features an introduction to the new API, an interview with a Google Drive engineer about the API design and a code walkthrough of real source code you can use today (as with all my Launchpad Online episodes). This time, it's a command-line script that performs Google Drive file uploads and downloads, presented first in v2 followed by a how-to segment on migrating it step-by-step to v3. In addition, the uploading segment includes the option of converting to Google Apps formats while the download portion covers exporting to alternative formats such as PDF®.
To get started using the Drive API, check out the links to the official documentation above (v2 or v3) where you’ll also find quickstart samples in a variety of programming languages to the left. For a deeper dive into both Python code samples covered here, including v3 migration, start with the first of two related posts posted to my blog.
If you’re new to the Launchpad Online, we share technical content aimed at novice Google developers -current tools with a little bit of code to help you launch your next app. Please give us your feedback below and tell us what topics you would like to see in future episodes!
Posted by Matt Hessinger, Project Specialist, Google Apps Script
Welcome to our 100th blog post on Apps Script! It’s amazing how far we’ve come from our first post back in 2010. We started out highlighting some of the simple ways that you could develop with the Apps platform. Today, we’re sharing tips and best practices for developing more complex Apps Script solutions by pointing out some community contributions.
The Apps Script editor does not allow you to use your own source code management tool, making it a challenge to collaborate with other developers. Managing development, test, and production versions of a project becomes very tedious. What if you could have the best of both worlds — the powerful integration with Google’s platform that Apps Script offers, along with the development tooling and best practices that you use every day? Now, you can.
npm install -g node-google-apps-script
This project, “node-google-apps-script”, is a Node.js based command-line interface (CLI) that uses Google Drive API to update Apps Script project from the command line. You can view the node package on the NPM site, and also view the GitHub repo. Both links have usage instructions. This tool was created by Dan Thareja, with additional features added by Matt Condon.
Before using the tool, take a look at the Apps Script Importing and Exporting Projects page. There are a few things that you should be aware of as you plan out your development process. There are also a few best practices that you can employ to take full advantage of developing in this approach.
There is a sample project that demonstrates some of the practices described in this post: click here to view that code on GitHub. To get all of the Apps Script samples, including this import/export development example:
Your standalone Apps Script projects live in Google Drive. If you use a command-line interface (CLI) tool like the one linked above, you can work in your favorite editor, and commit and sync code to your chosen repository. You can add tasks in your task runner to push code up to one or more Apps Script projects, conditionally including or excluding code for different environments, checking coding style, linting, minifying, etc. You can more easily create and push UI-related files to a file host outside of Apps Script, which could be useful if those same files are used in other apps you are building.
In addition to the information on the Importing and Exporting Projects page, here are a few things to consider:
Over and above the editing experience, the biggest improvements you get by working outside the script editor is that you are no longer locked into working in just one Apps Script project. You can much more easily collaborate as a team, with individual developers having their own working Apps Script projects, while also having more controlled test, user acceptance and production versions, each with more process and security. Beyond just the consistency with other normal project practices, there are a few Apps Script specific ways you can leverage this multi-environment approach.
If you are going to use this approach, here are three best practices to consider:
The provided sample shows a simple example of how a base configuration class could allow a developer to inject their local values for their own debugging and testing. In this case, the developer also added the annotation @NotOnlyCurrentDoc, which tells Apps Script that they need the full scope for Drive API access. In this project, the “production” deployment has the annotation @OnlyCurrentDoc, which leads to the OAuth scope that is limited to the document associated with script running as Sheets, Docs, or Forms add-on. If you add a standard file pattern to the source project’s “ignore” file, these developer-specific files will never get into the actual codebase.
Benefits for your project — Production can have more limited OAuth scopes, while a developer can use broader access during development. Developers can also have their own personal configuration settings to support their individual development efforts.
While there is no current way to trigger tests in an automated way, you still may want to author unit tests that validate specific functions within your projects. You’ll also likely have specific configuration values for testing. Once again, none of these files should make it into a production deployment. You can even use the Apps Script Execution API to drive those tests from a test runner!
Benefits for your project — You can author test functions, and keep them separate from the production Apps Script file. This slims down your production Apps Script project, and keeps the correct OAuth scopes that are needed for production users.
If you are developing an add-on for Sheets or Docs, and you expect to have an “active” item on the SpreadsheetApp. However when you are developing or testing, you may be running your Apps Script without an “active” context. If you need to develop in this mode, you can wrap the call to get the current active item in a method that also can determine what mode you are running in. This would allow your development or test instance to inject the ID of an “active” document to use for testing, while delegating to the getActive* result when running in a real context.
Benefits for your project — You can integrate better unit testing methodologies into your projects, even if the end deployment state dependents on resources that aren’t typically available when debugging.
You now have the option to use your own development and source management tools. While you still do need to use the Apps Script editor in your application’s lifecycle — to publish as a web app or add-on, configure advanced services, etc. — taking this step will help you get the most out of the power of the Apps Script platform. Remember to check out Apps Script on the Google Developers site to get more information and samples for your Apps Script development.
If you happen to use python tools on the command line to facilitate your team’s build process, you can check out Joe Stump's python-gas-cli. You can view the package info here or the GitHub repo where you’ll also find usage instructions.
Here are some additional reference links related to this post:
Posted by Muzammil Esmail, Product Manager, Google for Work and Wesley Chun, Developer Advocate, Google Apps
Over the years, we’ve been updating our APIs with new versions across Drive and Calendar, as well as those used for managing Google Apps for Work domains. These new services offer developers improvements over previous functionality and introduces new features that help Apps administrators better manage their domains.
To deliver even more granular control, today we are announcing the new Calendar Resource API as part of the Admin SDK’s Directory API that enables Google for Work customers to manage their physical resources, like conference rooms, printers, nap pods, tennis courts, walkstations, etc. These physical resources can be added to meetings by end users as needed. The API released today replaces the GDATA Calendar Resource API, so we encourage developers to begin moving their applications and tools to the new API. Please note that we will begin deprecation in January 2016 and sunset the existing API in January 2017. Stay tuned for a formal deprecation announcement with details.
Posted by Rishi Dhand, Product Manager, Google Apps Admin SDK and Wesley Chun, Developer Advocate, Google Apps
In a Google Apps domain, Admin role management (i.e. create, assign, and update admin roles) is a critical function for super admins that helps them distribute admin responsibilities in a more secure manner. Until now, this functionality was only available via the Admin console UI.
Today’s launch of the Roles API (one of the Admin SDK Directory APIs) enables developers to build admin tools that can perform role management programmatically.
This new API will be useful to admins who have either built internal admin tools using the Admin SDK, or developers of third-party admin tools. Both can now use the Roles API to provide selective access to Delegated Admins (DAs) to specific admin capabilities within third-party applications.
Here are some examples of use cases where the Roles API can be leveraged: