Exclusive: Google to offer feed API

Google plans to offer a feed reader API to allow third-party developers to build new views of feed data on top of Google’s backend. The new APIs will include synchronization, feed-level and item-level tagging, per-item read and unread status, as well as rich media enclosure and metadata handling. Google Reader PM Jason Shellen and engineer Chris Wetherell both confirmed Google’s plans after I posted my reverse-engineering analysis of the Google Reader backend.

The new APIs will allow aggregator developers to build new views and interactions on top of Google’s data. Google currently has at least two additional Google Reader views running on current development builds.

Google may offer public access to the feed API as early as next month. Shellen said the team wants to nail a few more bugs before publicly making the service available to the world.

Hopefully the Google team is considering offering API hosting and processing similar to Alexa’s platform. Hosting personal homepage widgets on Google Base is a good start but think about if developers could interact with data via JavaScript on the same domain as the service!

Google Desktop would be an ideal first implementation of the new APIs, centralizing Google’s feed retrieval and reducing load on individual servers. Google feed grabber, FeedFetcher, currently collects content for Google Reader and Google personalized homepage.

Google’s new offering is direct competition to NewsGator’s synchronization APIs but are easier to code against (no SOAP required). Google currently does not have the same reach across devices as NewsGator but an easy-to-use API from the guys who brought you the Blogger API and “Blog This!” might really shake up the feed aggregator ecosystem.

  • Posted
  • Updated at
  • Comments [8]


Commentary on "Exclusive: Google to offer feed API":

  1. mparaz on wrote:

    Nice to have the news break right here!

    The obvious thing for me that’s missing is: search feeds, and search the permalink pages.

    For API hosting, a shell login like Alexa may not be necessary. I could use the ability to run sandboxed Java code on the server-side. Hey wait, I think Technorati can do that already since you guys are (were?) using Lucene.

  2. Greg Linden on wrote:

    Wow, very cool, Niall!

  3. Ryan on wrote:

    It’s a shame people think SOAP is hard. With the right tools, SOAP is easier than dealing with custom XML formats.

  4. Danny on wrote:

    Nice work Niall! (and Jason & co, if you read this ;-)

    I’m curious to know what the terms of use will be. It would be marvellous to be able to use the service in mashup-style systems. But the restrictions on the search API and the relative inaccessibility of Google Base data don’t exactly bode well.

  5. Sarah on wrote:

    Very cool! I’m blogging this!

  6. pwb on wrote:

    It’s a shame people think SOAP is hard.

    People *know* SOAP is hard.

    With the right tools

    That’s one of the main problems. But why are tools needed for something that should be so simple?

  7. Chris Riley on wrote:


    Just wondering if you have any further info on when they might be releasing the Reader API. I’d really like to make use of it, but want to see how they plan to do the authentication first.

    Thanks for any info!