The Email Settings and the Profiles APIs

Updating all signatures to make them adopt the same visually appealing style sounds like a perfect task to automate, however we’d still need to collect various pieces of information for each user, such as phone number or job title, and the Email Settings API has no knowledge of them.

The Google Apps Profiles API provides exactly what we are looking for and in the rest of this article we’ll see how to have the two APIs interact to reach our goal.

Let’s assume we want our signatures to look like the one in the screenshot below, with a bold name, italic job title and clickable link for the email address. Of course you can edit the style as you like with a bit of HTML skills:

Python is the programming language of our choice for this small script and we use the Google Data APIs Python Client Library to send requests to the Email Settings and Profiles APIs.

The first few lines of the script import the required libraries and set the values of the credentials that will be used to authorize our requests. You can find the consumer key and secret for your domain in your Control Panel, under Advanced Tools – Manage OAuth domain key. Remember to replace the dummy values in the script below with yours before running it:

import gdata.apps.emailsettings.client

import gdata.contacts.client

# replace these values with yours

CONSUMER_KEY = 'mydomain.com'

CONSUMER_SECRET = 'my_consumer_secret'

company_name = 'ACME Inc.'

admin_username = 'admin'

We’ll use 2-legged OAuth as the authorization mechanism and set the administrator’s email address as the value of the xoauth_requestor_id parameter, identifying the user we are sending the requests on behalf of.

The consumer key and secret plus the requestor id are the only parameters needed to create an OAuth token that we can pass to the Email Settings and Profiles clients:

# request a 2-legged OAuth token

requestor_id = admin_username + '@' + CONSUMER_KEY

two_legged_oauth_token = gdata.gauth.TwoLeggedOAuthHmacToken(

  CONSUMER_KEY, CONSUMER_SECRET, requestor_id)

# Email Settings API client

email_settings_client = gdata.apps.emailsettings.client.EmailSettingsClient(

  domain=CONSUMER_KEY)

email_settings_client.auth_token = two_legged_oauth_token

# User Profiles API client

profiles_client = gdata.contacts.client.ContactsClient(

  domain=CONSUMER_KEY)

profiles_client.auth_token = two_legged_oauth_token

Let’s define a class that generates the signatures for our users on the basis of a set of optional attributes (occupation, phone number, email, etc). This is the class you need to edit or extend if you want to change the style of the signatures for your domain. In the example below, the HtmlSignature() method simply concatenates some strings with hard-coded styling, but you may want to use a more elaborate templating system instead:

# helper class used to build signatures

class SignatureBuilder(object):

def HtmlSignature(self):

  signature = '%s' % self.name

  if self.occupation:

    signature += '%s' % self.occupation

  if self.company:

    signature += '%s' % self.company

  signature += 'Email: %s - Phone: %s' % (

      self.email, self.email, self.phone_number)

  return signature

def __init__(

    self, name, company='', occupation='', email='', phone_number=''):

  self.name = name

  self.company = company

  self.occupation = occupation

  self.email = email

  self.phone_number = phone_number

Let’s use profiles_client to retrieve a feed containing all profiles for the domain. Each call to GetProfilesFeed() only returns a page of users, so we need to follow the next links until we get all users:

# get all user profiles for the domain

profiles = []

feed_uri = profiles_client.GetFeedUri('profiles')

while feed_uri:

  feed = profiles_client.GetProfilesFeed(uri=feed_uri)

  profiles.extend(feed.entry)

  feed_uri = feed.FindNextLink()

At this point profiles will contain the list of users we want to process. For each of them, we instantiate a SignatureBuilder object and set its properties name, company, occupation, email and phone_number with the data for that user.

A call to the HtmlSignature() method of the SignatureBuilder instance will provide us with a properly formatted HTML-encoded signature.

# extract relevant pieces of data for each profile

for entry in profiles:

builder = SignatureBuilder(entry.name.full_name.text)

builder.company = company_name

if entry.occupation:

  builder.occupation = entry.occupation.text

for email in entry.email:

  if email.primary and email.primary == 'true':

    builder.email = email.address

for number in entry.phone_number:

  if number.primary and number.primary == 'true':

    builder.phone_number = number.text

# build the signature

signature = builder.HtmlSignature()

The Email Settings API client exposes a method called UpdateSignature to set the signature for a target user. This methods accepts two parameters, the username of the user to be affected and a string containing the signature. We just built the latter, so we only need the retrieve the unique username that identifies each user and that can be easily inferred from the entry identifier returned by the Profiles API, as described in the code and the comment below.

It is worth mentioning that you can also retrieve usernames with the Provisioning API, but for the sake of simplicity we’ll rely on this small hack:

# entry.id has the following structure:

# http://www.google.com/m8/feeds/profiles/domain/DOMAIN_NAME/full/USERNAME

# the username is the string that follows the last /

username = entry.id.text[entry.id.text.rfind('/')+1:]

It’s time to send the requests to the Email Settings API and update the signature:

# set the user's signature using the Email Settings API

email_settings_client.UpdateSignature(username=username, signature=signature)

For further details on what can be accomplished with the Google Apps APIs, please check our documentation .

Help your customers stay in touch with Google Contacts

A while back we began a series of articles about integrating with Google Apps and the Google Apps Marketplace, starting with how to make a great first impression on your users. Today we’re continuing that series with an eye on collaboration and the various “people” APIs in Google Apps — Contacts, Shared Contacts, Profiles, and Provisioning.

Why contacts? Contacts data is used pervasively and makes it easier to share documents, arrange meetings, or communicate in general. It’s synced with mobile phones & email clients. Many apps in the Google Apps Marketplace use contacts to help users share projects and assign tasks to coworkers. In short, the contacts APIs act as a hub for applications and devices to share important information about the people users communicate and collaborate with the most!

Untangling the APIs

Before jumping in to how to use these APIs to make work easier for users, let’s take a step back and look at the role of each API.

Contacts API – This API provides access to an individual user’s personal contacts & is available to all users on all editions of Google Apps. Each user manages their own contacts separately.

Shared Contacts API – The shared contacts API is available only to Google Apps for Business and Education editions, and provides a way for domain administrators to manage a global address list of external (non-employee) contacts viewable by all users in the domain.

Profiles API – Like the Shared Contacts API, the profiles API is only available for Google Apps for Business and Education education, and is managed by domain administrators. But while shared contacts can be used to manage contact information for people outside the domain, the Profiles API is exclusively for managing contact information for users in the domain.

Provisioning API – A distant cousin of the others, the Provisioning API allows domain administrators to manage users, groups, and organizational units in their domain. While the full version of the API is restricted to Google Apps for Business & Education editions, all editions support a read-only view of the data and it can be a quick and easy way to discover organizational information for a domain.

Speeding Setup

As mentioned in our earlier post on creating a good initial experience, these APIs, can be a great way to help administrators set up and configure applications quickly. The provisioning API in particular is well suited to this and provides user, group, and organizational data for a domain.

Expensify uses the provisioning API to quickly configure roles and reporting relationships for submitting expense reports.

Making Users More Productive

There are a variety of ways to use the various contacts APIs to help users save time and be more productive. Project & task management apps often benefit from importing contact information to speed user entry.

Manymoon’s project management app helps users assign tasks quicker by auto-completing names as the user types.

Likewise, CRM and marketing automation apps can also speed user adoption and reduce the need for time consuming data entry by importing existing customer data stored in contacts.

Importing contacts to Bantam Live

Share and Share Alike

For applications that aim to be the system of record for contact or employee information, pushing data to Google Apps can be a big win both for users and developers. Syncing contact data with Google Apps means syncing with every other application and device that syncs as well. It allows developers to magnify the reach of their integrations and lets users access important partner data no matter what the context.

Sharing contacts with BatchBook

Full bi-directional contacts synchronization is more challenging. It can be equally rewarding. Not only does it allow users to edit contacts in context, it can enable innovative new services that seamless enhance data without disrupting how users work.

Rainmaker’s bi-directional sync automatically enhances contacts with data from social networks and other sources.

While the example so far have focused on the Contacts API and individual users, synchronization with the Shared Contacts API can provide added value for larger organizations on Google Apps for Business.

As our friends over at Manymoon wrote not too long ago, they learned three key lessons about what it takes to be successful in the Google Apps Marketplace: Appeal to a broad audience, integrate deeply, and demonstrate immediate value. Integration with contacts & provisioning APIs is a great way to do accomplish those goals that just about any app can benefit from!

Making your rounded models look better

When you’re working with rounded objects whose edges have been smoothed, it’s sometimes hard to make things look good. That’s because curved surfaces don’t automatically produce a profile edge that helps to differentiate them from the background. You can see what I’m talking about in the images that follow; notice the (what I consider to be) unsatisfying outline of each of the rounded objects below?

Without Profiles turned on, rounded objects don’t stand out.

Turning on Profiles in the Styles dialog box produces a completely different result. At a Profiles setting of 2 pixels, perimeter edges become clearly visible. They’re a little chunky, though—and that’s not always the effect I’m aiming for.

Profiles that are 2 pixels thick often look too bold and cartoony.

Dialing down Profiles to 1 pixel solves the problem (see below).

Using a Profile thickness of 1 pixel makes rounded objects pop out from the background.

While this trick might seem obvious, it actually took eight years to soak into my brain. I never understood the benefit of setting my profile thickness to a single pixel. After all, edges are already that thickness—why spend the computer cycles to draw them again? Now I know. I thought others might benefit from my epiphany, embarrassingly late though it is.

It’s worth mentioning that telling SketchUp to draw Profiles can slow things down considerably if your model’s pushing the limits of your polygon budget. I only switch Profiles on when I need them.

Posted by Aidan Chopra, SketchUp Evangelist