My favorites | English | Sign in

Google Health Data API

Developer's Guide: Protocol

Important: This is an old version of this page. For the latest version, use the links in the left-side navbar.

The Google Health Data API allows client applications to view and update Health content in the form of Google Data API feeds.

Your client application can create new entries, edit or delete existing entries, request a list of entries, and query for entries that match particular criteria.

In addition to providing some background on the capabilities of the Health Data API, this document provides examples of basic Data API interactions using raw XML and HTTP. After reading this document, you may want to learn more about interacting with the API using our client libraries by reading the programming-language-specific sections of this developer's guide.

Contents

  1. Audience
  2. Getting started
    1. Creating a Health account
  3. Authenticating to the Health service
    1. AuthSub (for web apps)
    2. OAuth (an alternative to AuthSub)
    3. ClientLogin (for installed/desktop apps)
    4. Additional resources
  4. Retrieving a profile
  5. Retrieving a list of notices
  6. Submitting a profile
  7. Posting new notices
  8. Querying for specific profile entries
  9. Editing entries
  10. Deleting entries
  11. Sending a single item exactly once
  12. Synchronizing data
  13. Batch processing

Audience

This document is intended for programmers who want to write client applications that can interact with Google Health.

The Google Health Data API generally serves two types of users:

  • Data partners, such as pharmacies or medical institutions, who have data to contribute.
  • Application partners, who will integrate with Google Health in order to read data and do something interesting with it. For example, a third-party service might be a clinical trial matching service that reads in a patient profile and alerts the patient to relevant clinical trials.

Some partners, like medical institutions, may be in both classes, since they both contribute to a patient's record, as well as read it to help provide care.

Below are a series of examples of basic Data API interactions using raw XML and HTTP, with explanations. Along with reading this document, you may wish to learn more about interacting with the API using our Google Data API client libraries by reading the language-specific examples found on the subtopics listed at the left of this document.

This document assumes that you know how Google Health works (profiles, notices, etc.) and have reviewed the Health Data API reference information.

This document also assumes that you understand the general ideas behind the Google Data APIs protocol and that you understand ATOM feeds and syntax.

If you're using a UNIX system and you want to try out the API without writing any code, you may find the UNIX command-line utilities curl or wget useful; for more information, see the manual pages for those utilities. To get started with curl, see Using cURL to interact with Google Data services.

Back to top

Getting started

Creating a Health account

You may want to sign up for a Health account for testing purposes. Health uses Google Accounts, so if you already have a Google account, you're all set.

Back to top

Authenticating to the Health service

Choosing an authentication method

AuthSub and OAuth are the recommended methods of authenticating web applications because it allows a user to connect with Google without having to use their login credentials explicitly. If you are developing a standalone installed/desktop application, ClientLogin is the most appropriate method.

AuthSub

AuthSub proxy authentication allows users to link their Google Health accounts between external websites and Google without requiring the user to share their username and password with the external site or vice versa. Instead of explicit usernames and passwords, a token is exchanged, allowing external websites to associate the user's account with a specific account on Google Health. Subsequently, your website acts on behalf of the user by submitting that token as an authentication credential to Google Health.

When a user visits your application for the first time, they will have to grant access to their Health data. You can start the AuthSub process by directing the user to a Google page to authorize your request for access to their profile(s).

Note: Google Health has its own AuthSubRequest handler at https://www.google.com/health/authsub?.... This is different from the normal AuthSubRequest page, https://www.google.com/accounts/AuthSubRequest?....

The AuthSubRequest URL might look like this:

https://www.google.com/health/authsub?scope=https%3A%2F%2Fwww.google.com%2Fhealth%2Ffeeds%2F&session=1&secure=1&permission=1&next=http%3A%2F%2Fwww.example.com%2Fwelcome

The following table lists the acceptable parameters for AuthSub:

ParameterDescription
scope (required) For Google Health, this parameter should be set to https://www.google.com/health/feeds/.
secure (optional) Integer value indicating whether a secure AuthSub token must be used. This parameter cannot be set to 0.
Default: secure=1
session (required) This parameter should be set to 1 in the case of Google Health. Single-use AuthSub tokens (session=0) are not supported.
Default: session=0
next (required) This parameter should be set to the URL of your web application. AuthSub will return the user to this URL after they link their profile and append a single-use token query parameter. This parameter corresponds to the target URL you register using the ManageDomains Tools.
(ex. next=http://www.example.com/processToken.php)
permission (optional) Integer value that presets the default permission level on the authsub page.
  • 0 = only send (POST) new notices.
  • 1 = read from profile and send new notices.
Default: permission=0

Note: For an added level of security, all AuthSub requests to Google Health must be signed (i.e. secure=1).

After the user grants access, AuthSub redirects them to the URL you specified in the next query parameter in the initial /health/authsub request URL. AuthSub appends an authentication token to that URL, as the value of the token query parameter. For example, if the previous query were successful, it would return this:

http://www.example.com/welcome?token=yourAuthToken

This token value represents a short-lived/single-use AuthSub token. In this example, since session=1 was specified, the token should be exchanged for an AuthSub session token by calling the AuthSubSessionToken service with the single-use token in an Authorization header.

Note: The request to AuthSubSessionToken must be digitally signed, because the initial request for a single-use AuthSub token was for a secure token.

Here's an example AuthSubSessionToken request:

GET /accounts/AuthSubSessionToken HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Authorization: AuthSub token="yourAuthToken" 
    data="GET https://www.google.com/accounts/AuthSubSessionToken 1148503696 15948652339726849410" sig="MCwCFrV93K4agg==" sigalg="rsa-sha1"
User-Agent: Java/1.5.0_06
Host: https://www.google.com
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive

Here's an example AuthSubSessionToken response:

Token=yourSessionToken
Expiration=20061004T123456Z

The AuthSubSessionToken response body includes a Token line that contains your session token. You can ignore the Expiration line, as AuthSub tokens do not expire unless explicity revoked. Your application can use the session token value in the Authorization header of subsequent interactions with Google Health.

Here's an example of an HTTP request that you might send. Notice the secure session token is in the Authorization header:

GET /health/feeds/profile/default  HTTP/1.1
Host: https://www.google.com 
Content-Type: application/atom+xml
Authorization: AuthSub token="yourSessionToken" 
    data="GET https://www.google.com/health/feeds/profile/default 1148503696 15948652339726849410" sig="MCwCFrV93K4agg==" sigalg="rsa-sha1"
Connection: keep-alive

Again, this request is signed.

There is a limit to the number of active tokens that can be issued against an account so services should revoke session tokens before discarding them.

For more information on constructing the signature and Authorization header, see the reference links at the end of this authentication section.

OAuth

Google Health supports OAuth, an open standard for authenticating and sharing your data with web applications. In many ways, OAuth is similar to the "registered with enhanced security" option of AuthSub. Once you have an OAuth access token, your client may send requests by constructing an appropriate base string and Authorization header.

Example request

To send an HTTP GET to https://www.google.com/health/feeds/profile/default?digest=true, you first need to construct the oauth_signature parameter.

The signature base string would look like this:

GET&https%3A%2F%2Fwww.google.com%2Fhealth%2Ffeeds%2Fprofile%2Fdefault&digest%3Dtrue%26oauth_consumer_key%3Dexample.com%26oauth_nonce%3D7b5455841eeb...%26oauth_signature_method%3DRSA-SHA1%26oauth_timestamp%3D1219627598%26oauth_token%3D1%252F_AnWPB51nTvo8n9Sw...%26oauth_version%3D1.0

Set the oauth_signature to the result of signing the base string with the algorithm specified in oauth_signature_method. The example request would look like this:

GET /health/feeds/profile/default HTTP/1.1
Host: https://www.google.com 
Content-Type: application/atom+xml
Authorization: OAuth oauth_version="1.0", oauth_nonce="7b5455841eeb...", oauth_timestamp="1219627598", oauth_consumer_key="example.com", oauth_token="1%2F_A4WPB5Tvo8n9Sw...", oauth_signature_method="RSA-SHA1", oauth_signature="HwTcwP5WSPOmgk%2Bm...vdnDs3ask%3D"

This example assumes example.com has already been registered with Google and Google Health. See Domain Registration & Signing Requests in the Getting Started Guide.

For more information on constructing the OAuth base string and Authorization header, see the reference links at the end of this authentication section.

ClientLogin username/password authentication

Use ClientLogin authentication if your client is a standalone, single-user "installed" client (such as a desktop application). To request an authentication token using the ClientLogin mechanism, send a POST request to the following URL:

https://www.google.com/accounts/ClientLogin

The POST body should contain a set of query parameters that look like parameters passed by an HTML form, using the application/x-www-form-urlencoded content type. These parameters are:

Email
The user's email address.
Passwd
The user's password.
service
  • The service name for Google Health is health.
  • The service name for the H9 developer's sandbox is weaver.
source
Identifies your client application. Should take the form companyName-applicationName-versionID. The examples use the name exampleCo-exampleApp-1.

For more information about the parameters, see the Authentication for Installed Applications document.

If the authentication request fails, then the server returns an HTTP 403 Forbidden status code.

If it succeeds, then the server returns an HTTP 200 OK status code, plus three long alphanumeric codes in the body of the response: SID, LSID, and Auth. You can ignore the SID and LSID values. The Auth value is the authorization token that you'll need to send to Google Health with each of your subsequent requests, so keep a copy of that value.

Since all requests to private feeds require authentication, you have to set the Authorization header in all subsequent interactions with Google Health, using the following format:

Authorization: GoogleLogin auth=yourAuthToken

Where yourAuthToken is the Auth string returned by the ClientLogin request.

Note: Use the same token for all requests in a given session; don't acquire a new token for each Health request.

Note: As described in the ClientLogin documentation, the authentication request may fail and request a CAPTCHA challenge. If you want Google to issue and handle the CAPTCHA challenge, then send the user to https://www.google.com/accounts/DisplayUnlockCaptcha?service=health (rather than to the CAPTCHA-handling URL given in the ClientLogin documentation).

Need more information on authentication?

For detailed information on authenticating to the Google Health service, see these additional resources:

Retrieving a profile

This operation is available for AuthSub, OAuth, and ClientLogin. Only AuthSub is described here. For a description of the ClientLogin equivalent, see ClientLogin Feeds.

You can send an HTTP GET request to the following URL to retrieve each profile item associated with the supplied token as a separate ContinuityOfCareRecord (CCR) document:

https://www.google.com/health/feeds/profile/default

Adding in the digest parameter retrieves the entire profile feed as a single CCR document:

https://www.google.com/health/feeds/profile/default?digest=true

The response is a feed that contains that user's profile:

<?xml version="1.0"?>
<feed
    xmlns="http://www.w3.org/2005/Atom" 
    xmlns:openSearch="http://a9.com/-/spec/opensearchrss/1.0/" 
    xmlns:ccr="urn:astm-org:CCR">
  <id>https://www.google.com/health/feeds/profile/default</id>
  <updated>2007-08-27T21:46:59.539</updated>
  <category scheme="http://schemas.google.com/g/2005#kind" term="http://schemas.google.com/health/kinds#profile"/>
  <link rel="self" type="application/atom+xml" href="https://www.google.com/health/feeds/profile/default"/>
  <openSearch:startIndex>1</openSearch:startIndex>
  <entry>
    <id>https://www.google.com/health/feeds/profile/digest/key_digest</id>
    <category scheme="http://schemas.google.com/g/2005#kind" term="http://schemas.google.com/health/kinds#profile"/>
    <ContinuityOfCareRecord xmlns="urn:astm-org:CCR"> 
      ... information here ...
    </ContinuityOfCareRecord>
  </entry>
</feed>

For information about what each of those elements means, see the Google Data APIs Protocol Reference document or the Atom 1.0 specification.

HTTP error codes

If your request fails for some reason, Google Health may return an error status code. More information about HTTP status codes is also available in the Google Data APIs Protocol Reference document.

Back to top

Retrieving a list of notices

This operation is only available under ClientLogin.

Send an HTTP GET to the following URL with the user's profile ID to retrieve the list of notices for that user:

https://www.google.com/health/feeds/register/ui/profileID

The response is a feed that lists all of that user's notices. Each entry in the feed represents a notice associated with the user. For example, a feed might look like this:

<?xml version="1.0"?>
<feed 
    xmlns="http://www.w3.org/2005/Atom" 
    xmlns:openSearch="http://a9.com/-/spec/opensearchrss/1.0/" 
    xmlns:ccr="urn:astm-org:CCR" 
    xmlns:gd="http://schemas.google.com/g/2005" 
    xmlns:gAcl="http://schemas.google.com/acl/2007" 
    xmlns:batch="http://schemas.google.com/gdata/batch" 
    xmlns:h9m="http://schemas.google.com/health/metadata">
  <id>https://www.google.com/health/feeds/register/ui/profileID</id>
  <updated>2007-10-12T22:03:56.410</updated>
  <link 
    rel="http://schemas.google.com/g/2005#feed" 
    type="application/atom+xml" 
    href="https://www.google.com/health/feeds/register/ui/profileID"/>
  <link 
    rel="http://schemas.google.com/g/2005#post" 
    type="application/atom+xml" 
    href="https://www.google.com/health/feeds/register/ui/profileID"/>
  <link 
    rel="http://schemas.google.com/g/2005#batch" 
    type="application/atom+xml" 
    href="https://www.google.com/health/feeds/register/ui/profileID/batch"/>
  <link 
    rel="self" 
    type="application/atom+xml" 
    href="https://www.google.com/health/feeds/register/ui/profileID"/>
  <openSearch:startIndex>1</openSearch:startIndex>
  <entry>
    <id>https://www.google.com/health/feeds/register/ui/profileID/key</id>
    <published>2007-09-25T22:10:37.658Z</published>
    <updated>2007-09-25T22:10:37.754Z</updated>
    <category 
      scheme="http://schemas.google.com/g/2005#kind" 
      term="http://schemas.google.com/health/kinds#register"/>
    <title type="text">test notice</title>
    <content type="text">testing</content>
    <link 
      rel="alternate" 
      type="text/xml" 
      href="https://www.google.com/health/feeds/register/ui/profileID/key"/>
    <link 
      rel="self" 
      type="application/atom+xml" 
      href="https://www.google.com/health/feeds/register/ui/profileID/key"/>
    <link 
      rel="edit" 
      type="application/atom+xml" 
      href="https://www.google.com/health/feeds/register/ui/profileID/key"/>
    <author>
      <name>localhost</name>
    </author>
    <ContinuityOfCareRecord xmlns="urn:astm-org:CCR">
      ... CCR data ...
    </ContinuityOfCareRecord>
  </entry>
</feed>

For information about what each of those elements means, see the Google Data APIs Protocol Reference document or the Atom 1.0 specification.

If you wanted to retrieve the notices as originally sent by others, set the original parameter to true (?original=true). By default, querying for a list of notices will return only the CCR elements that are understood by Google Health.

HTTP error codes

If your request fails for some reason, Google Health may return an error status code. More information about HTTP status codes (including other error codes) is also available in the Google Data APIs Protocol Reference document.

Back to top

Submitting a profile

Once the client has been authenticated, it can publish profile entries to Google Health. The operation of submitting records directly to the profile is only available under ClientLogin; otherwise, use the register feeds to upload data.

First, create an XML representation of the post to publish. This XML needs to be in the form of an Atom <entry> element, which might look something like this:

<?xml version="1.0" encoding="utf-8"?>
<entry xmlns="http://www.w3.org/2005/Atom">
  <title type="text">Testing</title>
  <content type="text">Test data</content>
  <ContinuityOfCareRecord xmlns="urn:astm-org:CCR">
    ... optional CCR data ...
  </ContinuityOfCareRecord>
</entry>

To publish this entry, send it to the profile's register feed URL as follows. First, place your Atom <entry> element in the body of a new POST request, using the application/atom+xml content type. Then find the profile's register URL in the feed by locating the <link> element where the rel attribute ends with #post. The profile's register URL is given as the href attribute of this element, which will be in this format:

<link rel="http://schemas.google.com/g/2005#post" 
      type="application/atom+xml" 
      href="https://www.google.com/health/feeds/register/default"/>

Posting to the entry may look like this:

POST /health/feeds/register/default HTTP/1.1
Content-Type: application/atom+xml
Authorization: AuthSub token="yourSessionToken" 
    data="POST https://www.google.com/health/feeds/register/default 1148503696 15948652339726849410" sig="MCwCFrV93K4agg==" sigalg="rsa-sha1"
Host: www.google.com

<?xml version="1.0" encoding="utf-8"?>
<entry xmlns="http://www.w3.org/2005/Atom">
  <title type="text">Testing</title>
  <content type="text">Test data</content>
  <ContinuityOfCareRecord xmlns="urn:astm-org:CCR">
    ... optional CCR data ...
  </ContinuityOfCareRecord>
</entry>

Health creates a notice record of the post, and creates profile items for each entry in the CCR document. Each profile item is created using the entry you sent and the transaction should result in the return of an HTTP 201 CREATED status code, along with a copy of the new item in the form of an <entry> element. The entry returned is the same one you sent, but it also contains various elements added by Health, such as an <id> element.

HTTP error codes

If your request fails for some reason, Google Health may return an error status code. More information about HTTP status codes (including other error codes) is also available in the Google Data APIs Protocol Reference.

Querying for specific profile entries

The Google Health API lets you request a set of entries that match specified criteria, such as requesting entries created or updated in a given date range, or published by a particular author.

For example, to send a date-range query, add the updated-min and updated-max parameters to the request URL. See the supported query parameters for a comprehensive list.

To get all the medication that was updated from March 16, 2007 to March 24, 2007, send an HTTP request to the profile feed's URL:

GET /health/feeds/profile/default/-/medication/?updated-min=2006-03-16T00:00:00&updated-max=2006-03-24T23:59:59&digest=true HTTP/1.1
Content-Type: application/atom+xml
Authorization: AuthSub token="yourSessionToken" 
    data="GET https://www.google.com/health/feeds/profile/default/-/medication?updated-min=2006-03-16T00:00:00&updated-max=2006-03-24T23:59:59&digest=true 1148503696 15948652339726849410" sig="MCwCFrV93K4agg==" sigalg="rsa-sha1"
Host: www.google.com

(After you send the GET request, Health may return a redirect, depending on various factors. If so, send another GET request to the redirect URL.)

When you send that GET request, Health returns an HTTP 200 OK status code and a feed containing any Health feed posts that were created or updated in the date range you specified.

Back to top

Posting notices

Note: If you have authenticated via AuthSub, you may only insert an entry into the register feed. You may not update or delete entries on the register feed or change data on the profile feed if you have authenticated using AuthSub. For more information, refer to the Reference chapter.

This operation is available under both AuthSub and ClientLogin authentication.

Feed URIs:
https://www.google.com/health/feeds/register/default (AuthSub)
https://www.google.com/health/feeds/register/ui/profileID (ClientLogin)

To post a new notice on the register feed, send a POST request with the new entry in the message body. Here's an example using AuthSub:

POST /health/feeds/register/default HTTP/1.1
Content-Type: application/atom+xml
Authorization: AuthSub token="GD32CMCL25aZ-v____8B" 
    data="POST https://www.google.com/health/feeds/register/default 1148503696 15948652339726849410" sig="MCwCFrV93K4agg==" sigalg="rsa-sha1"
Host: www.google.com

<?xml version="1.0" encoding="utf-8"?>
<entry xmlns="http://www.w3.org/2005/Atom">
  <title type="text">THE NOTICE'S TITLE</title>
  <content type="text">THE NOTICES SUBJECT LINE</content>

  <ContinuityOfCareRecord xmlns="urn:astm-org:CCR">
    ... optional CCR data ...
  </ContinuityOfCareRecord>
</entry>

Back to top

Editing entries

Note: If you have authenticated via AuthSub, you may only insert an entry into the register feed. You may not update or delete entries on the register feed or change data on the profile feed if you have authenticated using AuthSub. For more information, refer to the reference chapter for information on the permitted operations for each authentication method.

This operation is only available under ClientLogin.

To edit an existing atom entry (either a notice or profile element such as a medication), send an HTTP PUT request to the atom entry's edit URI with the updated data in the message body:

PUT https://www.google.com/health/feeds/register/ui/profileID/entryID HTTP/1.1
Content-Type: application/atom+xml
Authorization: GoogleLogin auth=yourAuthToken

<?xml version='1.0' encoding='utf-8'?>
<entry xmlns='http://www.w3.org/2005/Atom'
xmlns:ccr='urn:astm-org:CCR'
xmlns:batch='http://schemas.google.com/gdata/batch'
xmlns:h9m='http://schemas.google.com/health/metadata'>
  <id>https://www.google.com/health/feeds/register/ui/profileID/entryID</id>
  <published>2008-08-06T00:37:25.319Z</published>
  <updated>2008-08-06T00:37:38.748Z</updated>
  <category scheme='http://schemas.google.com/g/2005#kind'term='http://schemas.google.com/health/kinds#register' />
  <title type='text'>Testing</title>
  <content type='html'>Test data</content>
  <link rel='http://schemas.google.com/health/data#complete'type='application/atom+xml'
  href='https://www.google.com/health/feeds/register/ui/profileID/entryID/-/%7Bhttp%3A%2F%2Fschemas.google.com%2Fg%2F2005%23kind%7Dhttp%3A%2F%2Fschemas.google.com%2Fhealth%2Fkinds%23register' />
  <link rel='alternate' type='text/xml;charset=UTF-8'
  href='https://www.google.com/health/feeds/register/ui/profileID/entryID?alt=ccr' />
  <link rel='self' type='application/atom+xml'
  href='https://www.google.com/health/feeds/register/ui/profileID/entryID' />
  <link rel='edit' type='application/atom+xml'
  href='https://www.google.com/health/feeds/register/ui/profileID/entryID' />
  <author>
    <name>example.com</name>
    <uri>example.com</uri>
  </author>
  <ContinuityOfCareRecord xmlns='urn:astm-org:CCR'>
    ...
    <Body>
      <Medications>
        <Medication>
          <DateTime>
            <Type>
              <Text>Prescription Date</Text>
            </Type>
            <ExactDateTime>2007-03-09T12:00:00Z</ExactDateTime>
          </DateTime>
          <Type>
            <Text>Medication</Text>
          </Type>
          <Source>
            <Actor>
              <ActorID>Rx History Supplier</ActorID>
            </Actor>
          </Source>
          <Product>
            <ProductName>
              <Text>TIZANIDINE HCL 4 MG TABLET TEV</Text>
              <Code>
                <Value>-1</Value>
                <CodingSystem>omi-coding</CodingSystem>
                <Version>2005</Version>
              </Code>
            </ProductName>
            <Form>
              <Text>TAKE 1 TABLET BY MOUTH AT BEDTIME AS NEEDED FOR MUSCLE SPASM</Text>
            </Form>
          </Product>
          <Quantity>
            <Value>1</Value>
          </Quantity>
        </Medication>
      </Medications>
    </Body>
    ...
  </ContinuityOfCareRecord>
</entry>

Troubleshooting Tips:

Some firewalls block HTTP PUT messages. To get around this you can include the X-HTTP-Method-Override: PUT header in your requests: 

  PUT /health/feeds/register/ui/profileID/entryID HTTP/1.1
  Content-Type: application/atom+xml
  Authorization: GoogleLogin auth=yourAuthToken
  X-HTTP-Method-Override: PUT
  ...

Back to top

Deleting entries

Note: If you have authenticated via AuthSub, you may only insert an entry into the register feed. You may not update or delete entries on the register feed or change data on the profile feed if you have authenticated using AuthSub. For more information, refer to the reference chapter for information on the permitted operations for each authentication method.

This operation is only available under ClientLogin.

To delete an entry, send a DELETE request to the entry's edit URL. Here's an example of deleting a medical entry:

DELETE /health/feeds/register/ui/profileID/entryID HTTP/1.1
Authorization: GoogleLogin auth=yourAuthToken

This is the same URL used to update an entry.

Troubleshooting Tips:

Some firewalls block HTTP DELETE messages. To get around this you can include the X-HTTP-Method-Override: DELETE header in your requests: 

DELETE /health/feeds/register/ui/profileID/entryID HTTP/1.1
Authorization: GoogleLogin auth=yourAuthToken
X-HTTP-Method-Override: DELETE
...

Sending a single item exactly once

Institutions that integrate with Google Health to only send data, should only send information about each item exactly once. For example, if a user imports his prescription history from a pharmacy into Google Health, the pharmacy should send all records. Subsequently, when the user gets another prescription filled or refilled, the pharmacy should send only the new record, and not the records that had already been imported into the user's Google Health record. If the entire record were sent again, the user would have multiple copies of the earlier items, which would make for a confusing user experience.

Back to top

Synchronizing data

For a variety of reasons, services may desire to keep a parallel copy of a user's health data and synchronize periodically. To avoid creating duplicate copies, services connecting to health should be sure to send a single item exactly once

In addition, after every sync (including the first download), services should keep track of the date of last synchronization. For each future synchronization, services can query using the updated-min query parameter to see which items have changed. A list of Atom IDs will be returned, and will include IDs for items that were added, updated, or deleted. The service can then query on each of those IDs and get the latest copy. If an item was deleted, attempting to get the latest copy will only return that the item associated with that ID has been deleted.

For those whom synchronization is very important, the service can read the response to their submission and extract the associated Atom ID (found in the value of each item's CCRDataObjectID). The service can then store that ID with its internal representation of that object. Using that stored ID, the service can reference and track each specific item. Alternatively, after submitting the CCR document at time X, the service can query the profile feed for entries created between time X and X+1 and extract the value of CCRDataObjectID that way.

Back to top

Batch processing

Refer to the Google Data API document on Batch processing documentation for more information.

Back to top