Our API directory now includes 93 events APIs. The newest is the Eventility API. The most popular, in terms of mashups, is the Eventful API. We list 46 Eventful mashups. Below you’ll find some more stats from the directory, including the entire list of events APIs.

In terms of the technical details, REST and XML lead the way. There are 75 events REST APIs and 9 events SOAP APIs. Our directory lists 62 events XML APIs and 54 events JSON APIs.

The most common tags within events are 21 music events APIs, 15 social events APIs, 12 calendar events APIs and 12 tickets events APIs.

On the mashup side, we list 175 events mashups. We named Travel Baseball Team Locator as mashup of the day last week.

For reference, here is a list of all 93 events APIs.

  30 Boxes API: Calendar service

  5gig API: Concert listing service

  Active API: Events, Activities, Races, Tournaments, Classes

  Activism Network Community API: Online activism network and community

  Adobe on AIR Bus Tour API: Services to track Adobe AIR product launch

  Amiando API: Events organizing and ticketing services

  ArtBeat API: NYC/Tokyo art events information

  AttendStar API: Online event ticketing and promotion service

  Avacaster API: Event Management for Avacaster webservice

  Bandsintown API: Music concerts and recommendations service

  BeThereNYC API: New York City event listing

  Boomloop API: Local events and community

  Brown Paper Tickets API: Events Listing and Ticketing Service

  Bullseyehub API: Event promotion service

  Burning Man API: Event database

  Certain API: Event management service

  Community Megaphone API: Event listing service

  CS50 HarvardEvents API: Harvard Events Calendar

  Daum Events API: Movie and festival search service

  DoStuffMedia API: Music festival data lookup service

  Eventbrite API: Event registration, marketing, and promotion services

  Eventfinder API: New Zealand events calendar

  Eventful API: Local events discovery and demand

  Eventification API: Social Event Site

  Eventility API: Event organization and promotion service

  FanSnap API: Ticket search service

  Festivalslab API: Event information service

  Fizber Events API: Local events search services

  Fusicology API: Music and progressive entertainment hub

  Fuze Box API: Internet and mobile communication services

  Gatekrash API: UK event listings service

  GigJunkie API: Music events services

  GigMasters API: Entertainment booking service

  Gigulate API: Music blogging service

  Google Calendar API: Calendar service

  Happenr API: Events database

  Happenstand API: Bay area events listing service

  HubSpot Events API: Marketing events information service

  Hyperpublic API: Geographic data collection service

  Ignyte Movies and Showtimes API: Local movie showtime service

  Incubate API: Music and culture festival program listing service

  InstantEncore Maestro API: Classical music community

  JamBase API: Live music and concert information

  Kijubi API: Activity marketplace service

  KillerTours.com API: Band and Concert Search Tool

  LearningSource API: Online events platform

  Live Matrix API: Internet event listing service

  Live Nation Event Data API: Live music and concert information

  Livekick API: Concert and events recommendation service

  Localstreamer API: Geolocation service

  Lollapalooza API: Music event reference

  Malmöfestivalen API: Malmö Festival schedule and information

  Meetup API: Social events service

  Memory Reel API: Event marketing service and event mobile application provider

  MotorsportReg.com API: Motorsports events and calendar service

  Mycitymate Location API: Local user reviews and city guides

  New York Times Events API: Event listing service

  Orange Personal Calendar API: Calendar service

  PartySpark API: Social events service

  PartySync API: Messaging services

  Plakatt API: Searchable Events Database

  Plancast API: Social event service

  Plings API: Places and Activities Database

  Presdo API: Social events service

  Proxomo API: Social app development platform

  Sapo Agenda API: Events schedule service

  SCHED* API: Social Scheduling For Events

  SeatGeek API: Tickets search service

  Seattle 2.0 API: Seattle upcoming tech events

  Seatwave API: Online marketplace for live events

  ShowClix API: Ticket search service

  Skiddle API: UK events guide

  Smynx API: Search and coordination services for meeting up

  Social Actions API: Volunteer and charity opportunities services

  Socializr API: Event listing service

  Songkick API: Music concert and event community

  SonicLiving Concerts API: Online concert listing service

  Spongecell API: Online calendar service

  Spraci API: Events and clubs database

  TeliaSonera Calendar API: Calendar creation tool

  Thrillcall API: Music concert, tickets and tour information

  Ticket Evolution API: Secondary ticket sales software

  TicketCity API: Event ticketing service

  Ticketfly API: Music events and ticketing service

  TicketLeap API: Ticket information service

  TicketStumbler API: Ticket search service

  Tweetvite API: Tweetup and event creation service

  Upcoming.org API: Collaborative event calendar

  VenueCost API: Event and Venue Pricing Database

  Vitalist API: Project tracking and tasks

  Wots-On API: Event promotion service

  YouPage API: Business and local events directory

  Zvents API: Local events search and community

Sponsored by

Related ProgrammableWeb Resources Eventful API Profile, 46 mashups

Google opened its OAuth 2.0 playground to developers last November with support for Google properties and non-Google APIs with support for OAuth 2.0 draft 10. Since then, the company has added a number of new toys to the OAuth Playground, including support for testing client-side apps, in addition to testing Web-based applications.

In case you missed it the first time around, the OAuth Playground is a Google-sponsored site that allows developers to work with the OAuth 2 protocol.

Sponsor

Since the release, Google has added support for the client-side flow, which allows developers to test out client applications using the playground. (See also, Facebook's developer docs on client-side flow.)

They've also added support for newer OAuth 2.0 drafts. This gives developers access to drafts up to the March 8th draft (25). Since the Internet does not move at a uniform pace, developers still have access to earlier drafts, as well.

Spending a long time working with an application? The playground now has support for auto-refreshing access tokens – so you don't have to worry about timeouts.

The playground can be used for any OAuth apps, not just Google's services. However, if you're working with applications specific to Google services, you'll now find support for two parameters (access_type, approval_prompt) that are Google-specific. The playground also has support now for Google's API discovery service.

Whether you're working with Google services or just testing applications that need to use OAuth in general, the playground should be an excellent resource.

Discuss

This guest post comes from Peter Gruenbaum, founder of SDK Bridge. He has worked as an API writer to describe APIs for eCommerce, traffic prediction, electric utilities, mobile phones, and tractors, just to name a few.

From time to time, people who have a REST API ask me about automated documentation. There’s no one right answer, so I’ve been meaning for ages to write an article about what the options are. However, it’s only been recently that I’ve felt that I’ve understood the problems and solutions well enough.

Automated Documentation for REST APIs
People are constantly trying to come up with tools to make API documentation an easier task. If you are documenting an SDK built for C++, C#, or Java, there are tools such as Doxygen, Sandcastle, and JavaDocs to take comments from the code and automatically generate documentation from them. Why aren’t there tools like this for REST APIs?

The beauty of Web APIs is that they can be written in whatever language you like and in whatever manner you like. As long as when an HTTP request comes in, the proper HTTP response goes out, it doesn’t matter how it actually happens on the server. But this very flexibility makes automated documentation nearly impossible, since there’s no standard mapping between what an API request is and what the code is that generates its response.

Nonetheless, there are some solutions out there to this problem. I need to start by saying that there are in fact two approaches to automation that are used to document REST APIs. One is similar to the tools I mentioned above, where comments are taken from code to generate the documentation. The other involves having the documentation separate from the code, but in a data format (such as JSON) that can be parsed and used to generate the documentation.

I also should mention that documentation automation does not guarantee good documentation. Before choosing to to incorporate automation into your process, I recommend reading an excellent article by Dana Fujikawa: What to Consider Before Considering Auto-Generated Documentation.

Automated Documentation from Code
There’s no off-the-shelf tool that pulls documentation comments out of code that’s going to work for all REST APIs. But there are two possible solutions:

1. Use a framework that both generates the APIs and the documentation

2. Create methods with a one-to-one mapping with API requests.

Framework. A good example of a REST API framework is Enunciate. Enunciate is an open-source Java-based Web API framework. It creates full HTML documentation of the services it generates, where the documentation is assembled from JavaDocs comments.

Mapping. Mapping requires some disciplined practices, but has the advantage that it can be used with any technology. In this case, you need to create public methods that map directly to API requests. So, for example, you might have an API request to get a brief user profile for a user with an ID of 23423 with a call like this:

GET http://api.example.com/users/23423/profile?type=brief

When this request comes in, you need to structure your code so that it calls a method by the name of something like:

public get_users__id__profile(int id, string profile_type)

Note that the id is surrounded by double underlines, indicating that it is not literally the text “id”.

This method would then have comments that could be picked up by automated tool, such as JavaDoc, RDoc, or Sandcastle, and HTML documentation would be generated. Then you would need to run the HTML documentation through an automated process that would remove unnecessary information (such as class names), and convert the method names, replacing single underlines with slashes and double underlines with slashes and brackets so that

public get_users__id__profile

would become

GET /users/{id}/profile

The parameters table would also need some modification so that it’s clear which parameters are part of the URL and which are query parameters.

It’s not a simple process, but I have seen it done successfully using Ruby code and RDoc.

Automated Documentation from Structured Data
The advantage of taking comments from code is that if there are changes in the code, the comments are more likely to be updated. However, a simpler and very flexible solution is to have the documentation in structured data (JSON or XML), and then have an automated process create the actual HTML documentation from it. There are a several tools that will do this, merging documentation with an ability to try out the REST calls, which is extremely handy. Here are some examples.

Swagger. Swagger is a tool created by Worknik that creates very nice looking API documentation with the ability to easily try any API request. You specify a resource discovery URL which returns JSON with information about the various REST resources, then for each resource, you specify the type of operation, the path, the potential errors, and the response. Although you are limited in how long your descriptions can be, it creates a very nice documentation system for straight-forward APIs.

I/O Docs. I/O Docs is a tool created by Mashery that is very similar to Swagger. The big difference is that it is open source. Written in JavaScript, the source is available on github, which means that you can taylor it to your own needs, as well as look-and-feel.

Create your own. If neither of these tools are flexible enough for your API, you can create your own. A beautiful implementation that I had the priviledge to work on was created byTendril. Take a look at an example API request at Cost and Consumption for a Single Device. You can see how you can try it out on the first tab, but then other tabs list parameters, response, and notes. By creating their own system, they were able to document a fairly complex API call which would not have worked with an off-the-shelf system.

Conclusion
Automated REST API documentation can be used to:

• Keep the documentation near the code so that it’s easier to update.

• Allow developers to try out of the API requests as part of the documentation.

Although it is impossible to have a tool that automatically generates REST API documentation from any code, there are a number of approaches that will let you autogenerate the documentation, including:

• Using a framework that generates both the API code and its documentation.

• Creating a mapping between methods and API requests and using standard documentation tools.

• Writing documentation as structured data and generating HTML from it.

Sponsored by

Our API directory now includes 53 books APIs. The newest is the Readmill API, a social platform for eReaders which we recently covered. The most popular, in terms of mashups, is the Google Books API. We list 11 Google Books mashups. Below you’ll find some more stats from the directory, including the entire list of books APIs.

In terms of the technical details, REST and XML lead the way. There are 44 books REST APIs and 8 books SOAP APIs. Our directory lists 35 books XML APIs and 21 books JSON APIs.

The most common tags within books are 16 reference books APIs, 11 social books APIs and 10 library books APIs.

On the mashup side, we list 83 books mashups. We named Small Demons as mashup of the day in January.

For reference, here is a list of all 53 books APIs.

  Abundant Barnes & Noble Price API: Book price retrieval service

  aNobii API: Book sharing service

  Bertram Books API: UK book retailing service

  Bible Gateway API: Bible lookup services

  Bible Lookup API: Bible lookup service

  bkkeepr API: Book reading social services

  Blurb API: Social book publishing platform

  Bol.com API: Dutch online retail store

  Book Glutton API: Convert HTML to EPUB

  Bookleteer API: Craft booklet creation service

  BookMooch API: Books exchange service

  Bookshare API: Accessible Books For Readers with Print Disabilities

  Bookworm ePub Reader API: Online book management service

  Bowker Book Metadata Service API: Book descriptive metadata service

  CatalogWS API: Academic library

  Copac API: Search UK libraries

  Direct Textbook API: Book price comparison service

  ESV Bible Lookup API: Bible lookup service

  Feedbooks API: Mobile book and RSS services

  Goodreads API: Book search and social book services

  Google Book Search Book Viewability API: Book search

  Google Books API: Book search services

  Hathi Trust Data Distribution API: Library catalog search service

  hon.jp API: Japanese eBook metadata service

  I'vRead API: Social Reading Record

  iTrackmine Simple API: Collection sharing service

  Library of Congress SRW API: Information database search

  Library of Congress Subject Headings API: Access to the Library of Congress Subject Headings

  LibraryThing API: Books database and community

  Living Stones API: Bible lookup service

  Luzme API: Ebook price data engine

  New York Times Best Sellers API: New York Times best-seller lists data

  O'Reilly Product Metadata Interface API: Book and publishing industry metadata interface

  Open Library API: Library data access

  OReilly Safari API: Book search

  PaperBack Swap API: Book exchange service

  PubEasy API: Publishing and book sales information service

  Random House API: Book search and viewing service

  Readernaut API: Social book review service

  Readmill API: Online eBook discussion platform

  ReadSocial API: Social reading service for reading applications

  SendToReader API: Send web pages to Kindle devices

  SharedBook API: On-demand reverse publishing system

  SharedBookshelves API: Book sharing service

  TasteKid API: Taste discovery service

  Unglue.it API: Digital content relicensing service

  USA Today Best-Selling Books API: Best-Selling Books Information Service

  USA Today Book Reviews API: Book review service

  What's on My Bookshelf API: Book trading community service

  WorldCat Identities API: Library data access

  WorldCat Search API: Library data access

  WorldCat xISBN API: ISBN and book edition linking service

  Yonda4 API: Reading lists and recommendations

Sponsored by

Related ProgrammableWeb Resources Google Books API Profile, 11 mashups

Earlier this summer, author Jonathan Stark (@jonathanstark) launched a social experiment by releasing his Starbucks card to the general public. Based on the "take a penny, leave a penny" tray near some stores' cash registers, Stark encouraged people to use his Starbucks card — to spend the money on it and/or to add cash back to it. While Stark never put any stipulations on the process, some observers were taken aback when another developer, Sam Odio, explained how to use Jonathan's card to buy an iPad.

It's been several months since Starbucks shut down the experiment, and now that the frenzy around it has subsided, I asked Stark a few questions about what motivated him to begin the project and what he learned in the process.

Why did you launch the Jonathan's Card experiment?

Jonathan Stark: The motivation stemmed from my underlying belief that the vast majority of people are good. An opportunity to test this belief in public and on a global scale clicked with me at a very deep level. I couldn't have articulated this at the time, but it became very clear in retrospect.

For what it's worth, here's how the experiment got started:

I had been testing various mobile payment solutions while doing research for a client project. Starbucks' iPhone app was pretty cutting edge at the time, and I liked it. I wanted to test the app on an Android phone, but Starbucks had not yet released their Android app, so I took a screenshot of the in-app barcode on my iPhone and emailed the picture to my Android device. Sure enough, the barcode reader at the Starbucks point-of-sale (POS) system was able to read the picture of the barcode on my Android phone. This blew my mind because I had essentially emailed money to myself and bought physical goods with a digital photo.

A screenshot of Jonathan Stark's Starbucks card (click to enlarge).

As far as I knew, this was unprecedented. So, I did what any self-respecting geek would do: I blogged about it.

In the blog post, I invited readers to download the card image to their smartphones and see if it worked for them elsewhere in the US and around the world. It did work all over the US and in a handful of places outside the US. People who used it were amazed and delighted. It was really fun giving out free coffee, so I reloaded the card online a few times. Eventually it got a bit pricey, so I figured it'd be a once in a while thing.

Then one Saturday night, I noticed that my card balance had gone up. This freaked me out because the app is linked to my debit card and I thought someone might have guessed my starbucks.com password and was emptying my checking account. Fortunately, this was not the case. What had actually happened was that one of my friends discovered that he could anonymously add money onto my card using the picture of the barcode, either in person at the POS or by entering the number at starbucks.com.

At this point, my head exploded. I instantly realized that I could use the picture of the card to create a worldwide "pay it forward" experiment. I was up all night building a landing page that described the experiment, gave instructions on how to use the card, and how to donate to the card. I also wrote a script that scraped starbucks.com every minute for the current card balance — whenever the balance changed, the card would tweet its balance. When the card balance went to $0, it would tweet for help with a link to the instructions on how to donate.

What surprised you the most about the experiment?

Jonathan Stark: There were a lot of surprises. It's hard to say what surprised me most. Here's a list of biggies:

That Starbucks let the experiment go on for as long as it did. Sharing the card goes against the company's terms of use, and it could have been killed right away.

I was surprised how many people were perfectly comfortable with the concept of buying things with their phones. It seems to me that the average smartphone user is more willing to accept the "mobile wallet" concept than industry analysts would lead you to believe. I expected more people to have security concerns. I think I only got two questions about that.

How fast and huge something gets when it goes viral. I was getting contacted by network TV producers within days once the experiment took on a life of its own.

How addictive the Twitter feed was. By the end, @jonathanscard had more than 9,000 followers, many of whom later told me that they were watching it like TV, cheering when someone would make a big donation, booing when someone would spend $100 at a pop.

How generous most people are. I was amazed how many people were willing to throw $10, $20, even $50 into the pool to buy a coffee for some anonymous stranger. In one week, more than $19,000 went through the card.

How accommodating Starbucks baristas are. We heard stories about people bringing all sorts of wacky stuff up to be scanned: digital cameras, laptops, iPads, and so on. People who didn't have any mobile devices even took to printing the barcode out and scanning it like a coupon.

What are the broader implications from this experiment?

Jonathan Stark: There is no doubt in my mind that the experiment would not have taken off like it did without the Twitter feed. It was addictive, interactive, and simple. Once the community grew and started to engage with each other we had to create a Facebook page to allow people to have threaded conversations. Twitter became the card's data feed and Facebook was where people talked about it. Both were critical but in very different ways.

Starbucks doesn't have an API, which I think is a big missed opportunity. Retailers want to make sticky and engaging loyalty programs, right? One great way to do that would be to publish an API that allows third-party developers to build on top of a loyalty program in all sorts of delightful and unexpected ways. One thing everyone was asking for during the experiment was a heat map of where the purchase activity was taking place. Because there was no API, I couldn't provide this — which is too bad because it probably would have become viral in its own right.

Strata 2012 — The 2012 Strata Conference, being held Feb. 28-March 1 in Santa Clara, Calif., will offer three full days of hands-on data training and information-rich sessions. Strata brings together the people, tools, and technologies you need to make data work.

Save 20% on registration with the code RADAR20

This interview was edited and condensed.

Related

Lessons From the End of the Free Starbucks Card Experiment
Mobile payments target the point-of-sale
Who will own your mobile wallet?
3 mobile payments products hint at future

Many newspapers and other traditional media entities still think of themselves as delivering their content in a specific package, although most are trying hard to build an online readership as well, or experiment with iPad and Facebook apps (not to mention paywalls). But few are thinking about their businesses in radically different ways — as content-generating engines with multiple delivery methods, or as platforms for data, around which other things can be built. USA Today  appears to be moving in this direction, by opening up its data for others to use and even commercialize, following in the footsteps of The Guardian and its ground-breaking “open platform.”

USA Today has had an API (an “application programming interface,” which allows outside developers and services to access its content) for some time now, as many other newspapers such as the New York Times  do. But like most of those other media outlets, the terms of the USA Today content API said it could only be used for personal or non-commercial uses, which meant the range of applications that could make use of the paper’s content was extremely limited. Now, the Nieman Journalism Lab notes that the newspaper has changed the terms of its API, and will allow commercial licensing of its data, with no rate limits or data caps for these “premium” licenses.

Opening up a relationship with outside developers
The paper’s APIs include one for all of its news articles, one for reviews of books, movies and other entertainment, and one for its census data — which is made up of public data, but has been collected by USA Today and made available in a more usable format than the original government version (although most of its APIs require non-commercial use, the New York Times allows commercial use of its government-info API, which is also made up of public data). Stephen Kurtz, VP of digital development at USA Today, told the Nieman Lab that most of the developers interested in using the paper’s APIs for commercial use are “mom-and-pop” shops, or a couple of guys in a garage, mashing up the content they get with other sources — such as combining USA Today movie reviews with data from Netflix. Said Kurtz:

We encourage that, and they give us good feedback of what they’d like to see and how they would like the API to grow. So for us, it’s very symbiotic.

This is a smart way to think of what an open API accomplishes. It’s not so much that it’s going to generate huge sums of money for a newspaper that offers it, but it allows for experimentation outside the traditional confines of the publication itself — and that can generate valuable ideas and feedback. For The Guardian, which launched its “open platform” approach last year, the opening up of its API was very much an extension of editor-in-chief Alan Rusbridger’s belief in what he calls a “mutualized newspaper,” one in which readers and those outside the publication help on both the journalistic side and the development side.

Those outside the paper have good ideas too

As Chris Thorpe, then the Guardian‘s developer advocate, described in an interview with me last year when the open platform launched, the paper’s API allows for access on several levels. One is the original free level, which allows anyone to use the data for personal or non-commercial purposes; the second is a commercial license, which allows developers to make use of the API provided they agree to accept advertising within the content; and the third is a “bespoke” arrangement, in which developers can request specific data and work with the paper to build a service or app — and then share in the revenue generated from it.

The British paper has been inviting outside developers to make use of its APIs through a series of “hack days,” and they have come up with some interesting ideas. For example, Thorpe has a prototype of a site he calls the “Later Today” Guardian: the site takes the newslists that the newspaper recently made public, which detail which stories it is working on for a particular day, and then maps them against the stories that the paper actually produces. Not only that, but it also notes which ones are in the process of being updated, so readers with useful information can contact the author via Twitter or email.

It’s great that newspapers like the New York Times have “labs” like Beta620, where their staff can experiment with different formats and services based around their content. But one of the driving forces behind the Guardian open platform was the idea that the paper itself couldn’t possibly think of or develop every interesting or worthwhile project involving its content — so why not “crowdsource” that effort via the API? That’s a worthwhile attitude that more traditional media outlets could benefit from. Embedded below is the video interview I did with Thorpe when the open platform launched.



Watch this video for free on GigaOM



Post and thumbnail photos courtesy of Flickr users Arvind Grover and George Kelly

Related research and analysis from GigaOM Pro:Subscriber content. Sign up for a free trial.
Content Farms: The Players, The Benefits, The RisksFacebook and the future of our online livesNewNet Q1: Content Farms and Niche Networks on the Rise

If electronics and mechanics aren’t your strong suit, chances are you turn to the Internet to help fix your device. With you in mind, repair guide iFixit is aiming to become a platform to support all kinds of repair applications. The company has released an iFixIt API based on its user-contributed repair manuals.

iFixit CEO Karl Wiens calls it the world’s first repair API and stressed the need to create a “repair ecosystem.” The idea is to build a central and open platform for repair documentation. Developers are invited to write applications on top of this documentation and could include simple access applications to complex scenarios, where you integrate the repair documentation at the right time into an application that could be of use to field/service technicians. The holy grail, as iFixIt defines it, is “an always-with-you, up-to-date, instant-access repair manual for everything.”

The API is currently available and does not require an API key to begin with. The API is free to use for non-commercial purpose and in case you need it for commercial purpose or a higher rate, you can contact api@fixit.com for more details. It is not clear at this point what the rate limit is for free usage. The API is REST based, returns data in JSON format by default, with options for XML and JSONP.

In terms of functionality, the API provides access to iFixit’s repair manuals (step-by-step guides and device namespace pages) and device area hierarchy. It does not (yet) provide access to the parts or Answers Q&A database.

iFixit has also open sourced its iPad application, which gives developers some handy code to get started and create the early applications based on the iFixit API.

Sponsored by

Related ProgrammableWeb Resources iFixit API Profile