In a very inspiring announcement that reads like a rags to riches classic, Foursquare got on the SxSW train this year with a brand new client, containing an impressive list of functionality that has the potential to boost it from mere Social Game status to the Serendipity Platform that everyone’s waiting for.
This is what happened in their shop window. As it turns out, a lot more was happening in the engine room.
Before launching their new venues API (beta), finding something useful to do with Foursquare’s data was notoriously difficult.
Let’s take, for example, the problem of finding only venues with lots of checkins, in real time. This proved to be a major problem for us while building WOOS.at (mobile only)
These are the limitations:
- Foursquare’s normal API calls are rate limited to 500 calls an hour.
- Because of the low barrier to creating venues, the checkin-to-venue ratio is ridiculously low.
- A maximum of 50 venues can be queried from Foursquare per venue search on the API.
- There is no control over which venues are returned. If a venue is not in the 50 returned by a venue search, there’s no definite way of getting it.
- The search radius for venue searches on the API is 40km.
Given these limitations, it is possible to process 50 venues, 500 times an hour. This sounds like a lot, but 25000 venues an hour is not that much when you’re trying to discover trending venues in real time. Especially if you’re firing shots in the dark, and hoping for the best (hitting the same empty venues over and over).
In steps the new venues API.
At face level, it doesn’t look like much, until you give it a second look, and read the fine print:
- The new API is meant for userless access. This means it is built for bot usage, as opposed to front end usage. Ideal for determining venue trends in real time.
- The new API is rate limited at … 5000 calls an hour!
- There is a new API call, venues/trending, which automatically returns only the trending venues within a configurable radius (up to 2km)
Suddenly, even 500 calls an hour would’ve been enough.
Foursquare has a very vast location database. They have achieved this by making it extremely easy to create venues, and by being the first to do so. That is a very valuable resource, if dealt with correctly.
Up to now, Foursquare’s venues database was kind of proprietary, in the sense that its usability did not allow it to easily get a life of its own outside of Foursquare itself. It was mainly used for checkins.
By making their venue database accessible and usable, Foursquare have increased the value of the database by an immense amount. Add to this their actual reason for launching the new venues API: Mapping Foursquares venue data to other venue databases, like Facebook, Twitter and Google places.
Suddenly the future looks a lot brighter for Foursquare (and its API consumers)!
Posted by Adriaan Pelzer