Sean Kaiser (dot) com

A home for things (work-related & not) that I feel inclined to share with others.

Cross-domain Contact Sharing in Google Apps

| Comments

A bit of background

For our Google Apps implementation, we are using two different domains: one for staff and one for students. This was recommended to us by others, and we already owned the domains, so it made sense. The problem with this approach is that the user directory that allows users within a domain to simply type in a user’s name and then select their address from a list doesn’t work when some users are in one domain and the rest are in the other. Sure, each user could create the contacts in their personal contacts list, but for a teacher to create a new contact for each of their students would take considerable time. They’d also have to have access to the user list to know what the student email addresses are.


Google provides APIs to allow 3rd party scripts and solutions to interact with the domains. As we were setting up the domains, I remembered seeing something about a Shared Contacts API. Yesterday I started looking into what this API could do to help us solve the cross-domain contact issue. I found a Google Code project called Google Shared Contacts Client (or gscc for short for the rest of this document.) This python script lets you interact with the domain’s shared contacts.

To get started, you’ll need to follow the installation instructions. They’re simple. Be sure to install the GData Python client library, or nothing will work.

Export the domains’ contacts

Once you’ve got things installed, you will want to export your domains’ contact directories. From the gscc directory, you’ll want to run the command

$ python --export=domain1.csv

(You’ll need to change the administrative account and the export file name as you see fit.)

You’ll be prompted for your account password. This will generate a CSV file containing the specified domain’s users with their various email addresses and aliases/nicknames. Now, run the same command again, but specify an administrative account in your other domain, and export it to a different file.

Fix the files

The first couple of fields in each record are the action and id fields. The export files are meant to update existing contacts, rather than add them to the directory. As exported, the action is always update, and the id is the username. When adding a record to a domain, the action should be add (hopefully I didn’t just lose you there.) As I discovered today, when you’re adding a contact, the id field must be empty. How you choose to change this is up to you. You could open the file in Excel (yuck) to do a find & replace to change update to add, then clear the id column out. Or you could run the command

$ sed 's/^update,[a-z]*,/add,,/' < domain1.csv > domain1-fixed.csv

(This command assumes that your usernames are all lower case and don’t have special characters or numbers. If that’s not the case for you, you’ll need to change the sed command.)

Do this for both files.

Import each of the files into the other domain

The final step is to import the contact directory into the other domain. It’s simple. From the gscc directory, run the command

$ python --import=domain2-fixed.csv

(4/12/2011: fixed above command to reflect –import instead of –export)

Run the command again and switch domain1 and domain2.

Once you’ve imported the files, there’s nothing to do but sit back and wait for the changes to appear in the Contacts list. Google states it can take up to 24 hours for changes to the Shared Contacts list to show up.

Updating contacts list in the future

What happens if you’ve already loaded your domain’s contacts list, but get new staff or students? Maybe you want to add some addresses that are completely external to your domain. The easy way would be to create a CSV file that has the updated information in it. You don’t have to import a ton of empty fields. Create your file with the following fields (add additional fields if necessary, as specified in the gscc documentation):

Action,Name,E-mail address

Acceptable actions are add, update, and delete. You can mix and match actions in the same file. I suspect if you use the update or delete actions, you’ll need to have the id field included. The id field is shown in the output of the add process. You can either record it at that point, or you can run the export command and pull the id field from that file for the appropriate user(s).