Tag Archives: API

Automate unmanaged account onboarding with the User Invitation API beta

What’s changing


We’re adding a User Invitation API to the Cloud Identity API. This new API allows you to identify and manage unmanaged accounts

Unmanaged accounts are users with consumer Google accounts that share your organization's email address. The API will enable you to manage these accounts at scale, and automate sending of invites to these users to transfer their account to a managed state. to a managed state. 

The User Invitation API is initially available as an open beta, which means you can use it without enrolling in a specific beta program. See our documentation to learn more about how to use the API


Who’s impacted 

Admins 


Why you’d use it 

Unmanaged accounts occur when a user registers for a personal Google account using an email address that matches your domain. These accounts generally exist because a user has previously signed up for a personal Google Account using their work or educational email address. 

If your organization then signs up for Google Workspace or Cloud Identity and attempts to provision a managed account with the same primary email address, the conflict needs to be resolved. 

Previously, you could only manage these existing accounts via the Admin console. The User Invitation API provides another option which can help automate resolution of these conflicts, and can make it easier to manage these conflicts at scale. 


Getting started 

Rollout pace 

  • This feature is available now for all users in beta. 

Availability 

  • Available to all Google Workspace customers, G Suite Basic and Business customers, and Cloud Identity customers 

Resources 

Low-Power Sleep Tracking on Android

Posted by Nick Grayson, Product Manager

Illustration of phone with moon and Android logo on screen

Android works best when it helps developers create apps that people love. That’s why we are dedicated to providing useful APIs like Activity Recognition which, with the user’s permission, can detect user’s activities (such as whether a user is biking or walking) to help apps provide contextually aware experiences.

So much of what we do relies on a good night's rest. Our phones have become great tools for making more informed decisions about our sleep. And by being informed about sleep habits, people can make better decisions throughout the day about sleep, which affects things like concentration and mental health.

In an effort to help our users stay informed about their sleep, we are making our Sleep API publicly available.

What is the Sleep API?

The Sleep API is an Android Activity Recognition API that surfaces information about the user’s sleep. It can be used to power features like the Bedtime mode in Clock.

This sleeping information is reported in two ways:

  1. A ‘sleep confidence’, which is reported at a regular interval (up to 10 minutes)
  2. A daily sleep segment which is reported after a wakeup is detected

The API uses an on-device artificial intelligence model that uses the device’s light and motion sensors as inputs.

As with all of our Activity Recognition APIs, the app must be granted the Physical Activity Recognition runtime permission from the user to detect sleep.

Why is this important for developers?

Developers spend valuable engineering time to combine sensor signals to determine when the user has started or ended activities like sleep. These detection algorithms are inconsistent between apps and when multiple apps independently and continuously check for changes in user activity, battery life suffers.

The Sleep API is a simple API that centralizes sleep detection processing in a battery-efficient manner. For this launch, we are proud to collaborate with Urbandroid, the developer of the popular alarm app, Sleep As Android

Android logo sleeping
Sleep as Android is a swiss army knife for getting a better night’s rest. It tracks sleep duration, regularity, phases, snoring, and more. Sleep Duration is one of the most important parameters to watch for ensuring a good night’s rest. The new Sleep API gives us a fantastic opportunity to track it automatically in the most battery efficient way imaginable.

- Sleep as Android Team



When can I start using this API?

The Sleep API is available for developers to use now as part of the latest version of Google Play Services.

This API is one step of our efforts to help our users get a better night's rest. We look forward to working more on this API and in this area in the future.

If you are interested in exploring or using this API, check out our API Documentation.

New option to download third-party apps and domain wide delegation to CSV

Quick launch summary 

Google Workspace customers can set up and manage apps for app access control and domain-wide delegation through the Admin console at Admin console > Security > API Controls. However, for some customers the lists of apps in these sections can be long, which can make it difficult to see and manage the information in the Admin console. 


With this launch, we’re adding new options to download 3rd party API apps and domain wide delegated apps to a CSV file. This file will contain all the information which is displayed in the Admin console list. Having the information in CSV format may make it easier to understand and analyze how these apps and features are accessed in your organization. 


Getting started 

  • Admins: You’ll see the option to download app and client info at Admin console > Security > API Controls > App access control or Domain wide delegation. Use our Help Center to learn more about app access control and domain-wide delegation
  • End users: No end user impact. 

Rollout pace 

Availability 

  • Available to Google Workspace Essentials, Business Starter, Business Standard, Business Plus, Enterprise Essentials, Enterprise Standard, and Enterprise Plus, as well as G Suite Basic, Business, Education, Enterprise for Education, and Nonprofits customers 

Resources 

Automatic group membership management with dynamic groups, now generally available

Quick launch summary 

Dynamic groups are now generally available. Dynamic groups work the same as other Google Groups, but with the added benefit that their memberships are automatically kept up to date with a membership query. Dynamic groups can be based on one or many user attributes, including addresses, locations, organizations, and relations. 


By automating membership management you can increase security, reduce errors, and alleviate user frustration while minimizing the burden on admins. 


See our beta announcement for more details and example use cases for dynamic groups. Note that at launch, you won’t be able to manage policies—like context-aware access policies—using dynamic groups. We are working on adding this functionality in the future, and will announce it on the Workspace Updates blog when it’s available. 


This joins our other recent announcements for features that make it easier to manage groups within your organization. You can now also assign groups as security groups, set group membership expiration, and see indirect membership visibility and membership hierarchies via API. We hope these features make it easier to use groups to meet the access, security, and communication needs of your organization. 


Getting started 

Rollout pace 

Availability 

  • Available to Google Workspace Enterprise Standard, Enterprise Plus, Education Plus, and Cloud Identity Premium customers 
  • Not available to Google Workspace Essentials, Business Starter, Business Standard, Business Plus, Enterprise Essentials, and Education Fundamentals, or G Suite Basic, Business, and Nonprofits customers 

Resources 

Security groups now generally available

Quick launch summary 

We’re making security groups generally available. Security groups help you easily regulate, audit, and monitor groups used for permission and access control purposes by simply adding the security label. See our beta announcement for more details and use cases for security groups

We’ve recently announced several other features that can help you better manage groups in your organization and improve your security posture. These include group membership expiration and the indirect membership visibility and membership hierarchy APIs


Getting started 

Rollout pace 

Availability 

  • Available to Google Workspace Essentials, Business Starter, Business Standard, Business Plus, Enterprise Standard and Enterprise Plus customers, as well as G Suite Basic, Business, Education, Enterprise for Education and Nonprofits customers 

Resources 

Group membership expiration now generally available

Quick launch summary 

The Cloud Identity Groups API feature that enables you to set expirations for group memberships is now generally available. It was previously available in beta


This enables admins to set an amount of time that users and service accounts are members of a group. Once the specified time has passed, users will be removed from the group automatically. Automatic membership expiration can help reduce the administrative overhead for managing groups, and can help ensure group membership is limited to the members that need access. 




This launch is another enhancement to the Cloud Identity Groups API. We recently also made the indirect membership visibility and membership hierarchy APIs generally available. Together, these make it easier to manage permissions and access control in your organization. 


Getting started 

Rollout pace 

Availability 

  • Available to Google Workspace Enterprise Standard and Enterprise Plus, as well as G Suite Enterprise for Education and Cloud Identity Premium customers 
  • Not available to Google Workspace Essentials, Business Starter, Business Standard, Business Plus, and Enterprise Essentials, as well as G Suite Basic, Business, Education, and Nonprofits customers 

Resources 

Postmaster Tools API now available

Quick launch summary

We’re launching a Postmaster Tools API, allowing programmatic access to the email data found in the Postmaster Tools user interface. You can use the API to gather metrics on bulk emails sent to Gmail users—such as delivery errors, spam reports, feedback loop performance, and more. You can also import or merge the data into other systems and diagnose issues with email delivery.


Getting started

  • Admins: There is no admin control for this feature. 
  • End users: Registered domain owners can use this API to programmatically extract their domain’s data into their systems. Check out the Developers Guide to learn more about the using the Postmaster Tools API.

Rollout pace


Availability

  • Available to Google Workspace Essentials, Business Starter, Business Standard, Business Plus, Enterprise Essentials, Enterprise Standard, and Enterprise Plus, as well as G Suite Basic, Business, Education, Enterprise for Education, and Nonprofits customers

Indirect membership visibility and membership hierarchy APIs now generally available

Quick launch summary 

We’re making it easier to identify, audit, and understand indirect group membership via the Cloud Identity Groups API. Specifically, we’re making the membership visibility and membership hierarchy APIs generally available. These were previously available in beta. 

Using “nested” groups to manage access to content and resources can help decrease duplication, simplify administration, and centralize access management. However, nested groups can create a complex hierarchy that can make it hard to understand who ultimately has access and why. These APIs help provide all of the information you need to understand complex group structures and hierarchies, and can help you make decisions about who to add to or remove from your groups. 

See our beta announcement for more information and use cases for the APIs


Getting started 


Rollout pace 


Availability 

  • Available to Google Workspace Enterprise Standard and Enterprise Plus, as well as G Suite Enterprise for Education and Cloud Identity Premium customers. 
  • Not available to Google Workspace Essentials, Business Starter, Business Standard, Business Plus, and Enterprise Essentials, as well as G Suite Basic, Business, Education, and Nonprofits customers 

Resources 

Announcing new Real-time Bidding experiments

Google is launching experiments that are intended to provide bidders with an opportunity to test and provide collaborative feedback on ads-privacy proposals–these are features intended to improve user privacy protections and provide mechanisms for testing Chrome Privacy Sandbox proposals. We strongly encourage interested bidders to sign up and participate! Three new experiments made available today are described below.

Experiment #1: TURTLEDOVE simulation

The RTB protocols and infrastructure have been updated to enable a server-side simulation of Chrome’s TURTLEDOVE proposal, as described in the TURTLEDOVE simulation proposal. Bidders interested in participating can reference the TURTLEDOVE RTB Simulation API guide to learn more about the specific API and protocol changes associated with this experiment. Along with these changes, a new biddingFunctions resource for managing bidding functions that are used in the server-side simulation was added to the Real-time Bidding API.

The goal of this simulation is to provide bidders with an opportunity to experiment with Chrome’s proposal before it is implemented in Chrome, so that participating bidders can provide feedback on its viability and effectiveness. The APIs and modified RTB workflow used in the server-side simulation are conceptually similar to the ones that Chrome may later implement for TURTLEDOVE, based on existing proposals and public design discussions. Feedback relevant to Google’s simulation should be directed to the ads-privacy issue tracker, whereas feedback relevant to the TURTLEDOVE proposal itself should be directed to Chrome’s TURTLEDOVE issue tracker. To report bugs or technical questions about this experiment, you may contact the [email protected] support alias.

Experiment #2: Federated Learning of Cohorts (FLoC)

Google will allow participating bidders to experiment with Chrome’s FLoC proposal by simulating FLoC cohorts on its servers, based on algorithms described in this Google Research & Ads whitepaper. To facilitate this experiment, a Floc message has been added to the BidRequest in the Google RTB protocol, and as an extension of the User object for Google’s OpenRTB implementation. The message is structured as follows:


message Floc {
// The value of a cohort ID – a string identifier that is common to a large
// cohort of users with similar browsing habits.
optional string id = 1;
// The type of the FLoC. See
// https://github.com/google/ads-privacy/blob/master/proposals/FLoC/FLOC-Whitepaper-Google.pdf.
enum FlocType {
// Default value that should not be used.
FLOC_TYPE_UNKNOWN = 0;
// FLoC simulated using affinity hierarchical clustering with centroids
// and feature extraction based on Topic categories as described in the
// whitepaper.

SIMULATED_AFFINITY_CLUSTERING_CENTROID_VERTICAL = 2;
// FLoC simulated using SortingLSH clustering algorithm and Domain One-hot
// encoding feature extraction as described in the whitepaper.
SIMULATED_SIMHASH_SORTING_LSH_DOMAIN_ONE_HOT = 3;
// FLoC simulated using a k Random Centers locality-sensitive hash
// function as described in
// https://github.com/google/ads-privacy/blob/master/proposals/FLoC/k-random-centers.md
// with Domain TF-IDF feature extraction as described in the whitepaper.
KCENTER_DOM_FILTERED_TFDIF = 4;
}
optional FlocType type = 2;
}

Only web requests are in scope for the FLoC simulation experiment. In practice, only a small percentage of bid requests for bidders opted-in to the experiment would include this message, and those that do would not include pseudonymous user identifiers such as google_user_id and hosted_match_data.

Floc would also not be populated as a result of privacy controls, such as when users opt out of personalized advertising. Upon winning impressions, bidders can render creatives as usual and use their cookie-based identifiers to attribute conversions–for instance–to measure how well different FLoCs correlate with conversions.

We encourage participants to use the issue tracker to leave feedback on the simulated cohort algorithms. One useful metric to include would be the conversion rates for each FlocType in the experiment, possibly in comparison to regular traffic, where bidders may rely on cookie-based identifiers for targeting and optimization.

Experiment #3: Exchange-enforced frequency capping

The RTB protocols have been updated to enable an experiment for the exchange-enforced frequency capping proposal, which intends to support the critical frequency capping use case for the inventory provided by a single exchange without reliance on user identifiers provided in bid requests. A FrequencyCap message has been added to the BidResponse in the Google RTB protocol, and as an extension of the Bid object for Google’s OpenRTB implementation. The message is structured as follows:


  message FrequencyCap {
// An ID that can represent a bidder's use-case for frequency capping; for
// example, it could represent their campaign, ad, line item, etc. It should
// not contain any user-specific information or identifiers.
optional string fcap_id = 1;

// The time units for which frequency caps can be enforced.
enum TimeUnit {
UNKNOWN_TIME_UNIT = 0;
MINUTE = 1;
DAY = 2;
WEEK = 3;
MONTH = 4;
// When INDEFINITE is used, time_range will be ignored. INDEFINITE means
// the frequency cap will be applied for a long period of time, (longer
// than a month) but not necessarily forever.
INDEFINITE = 5;
}

// The unit of time used to specify the time window for which a frequency
// cap applies.
optional TimeUnit time_unit = 2;

// The length of the time window, in units specified by time_unit, for which
// the frequency cap applies. For instance, if time_unit=WEEK and
// time_range=3, then capping is applied for a three week period. If the
// time_unit=INDEFINITE, this will be ignored.
optional int32 time_range = 3 [default = 1];

// The maximum number of impressions allowed to be shown to a user for
// the provided frequency_cap_id within the time window described by
// time_unit and time_range.
optional int32 max_imp = 4;
}


Additional information about this experiment can be found in the proposal, and we encourage participants to leave feedback in the issue tracker.

Mark Saniscalchi, Authorized Buyers Developer Relations

The API Registry API

We’ve found that many organizations are challenged by the increasing number of APIs that they make and use. APIs become harder to track, which can lead to duplication rather than reuse. Also, as APIs expand to cover an ever-broadening set of topics, they can proliferate different design styles, at times creating frustrating inefficiencies.

To address this, we’ve designed the Registry API, an experimental approach to organizing information about APIs. The Registry API allows teams to upload and share machine-readable descriptions of APIs that are in use and in development. These descriptions include API specifications in standard formats like OpenAPI, the Google API Discovery Service Format, and the Protocol Buffers Language.

An organized collection of API descriptions can be the foundation for a wide range of tools and services that make APIs better and easier to use.
  • Linters verify that APIs follow standard patterns
  • Documentation generators provide documentation in consistent, easy-to-read, accessible formats
  • Code generators produce API clients and server scaffolding
  • Searchable online catalogs make everything easier to find
But perhaps most importantly, bringing everything about APIs together into one place can accelerate the consistency of an API portfolio. With organization-wide visibility, many find they need less explicit governance even as their APIs become more standardized and easy to use.

The Registry API is a gRPC service that is formally described by Protocol Buffers and that closely follows the Google API Design Guidelines at aip.dev. The Registry API description is annotated to support gRPC HTTP/JSON transcoding, which allows it to be automatically published as a JSON REST API using a proxy. Proxies also enable gRPC web, which allows gRPC calls to be directly made from browser-based applications, and the project includes an experimental GraphQL interface.

We’ve released a reference implementation that can be run locally or deployed in a container with Google Cloud Run or other container-based services. It stores data using the Google Cloud Datastore API or a configurable relational interface layer that currently supports PostgreSQL and SQLite.

Following AIP-181, we’ve set the Registry API’s stability level as "alpha," but our aim is to make it a stable base for API lifecycle applications. We’ve open-sourced our implementation to share progress and gather feedback. Please tell us about your experience if you use it.

By Tim Burks, Tech Lead – Apigee API Lifecycle and Governance