On API and digital methods

Just a couple months ago I was celebrating the release of the Meetup Archiver on Github. A little piece of software sending requests to Meetup.com and retrieving data via their official APIs. A software that, I wish, could be useful to many other researchers interested in analyzing Meetup data (a social network understudied, especially when compared to behemoths like Twitter and Facebook).

Today I logged into my own instance of the Meetup Archiver and I found out that the dataset hasn’t been updated since August. After a quick investigation, I found out that Meetup.com has changed the authentication method needed to use their API. Instead of an API key, now users need to authenticate using OAuth.

Moreover, in order to access the API you are asked to purchase a Meetup Pro account for $30/month. This means that at the moment I am not able to update my Meetup data and, therefore, I won’t be able to update the Startup Meetup dashboard I’ve been using for almost 2 years.

The only way to get access to the API, excluding the purchase a Pro plan for just using the API, is to get a OAuth Consumer Key. I have submitted a request for one and I hope that the research oriented and the non-profit nature of my application could help me get a key and continue my investigation.

Beyond the disappointment for the new API policy, this was a great example of what it means to work with platforms. What I I am learning in this painful transition is a lesson which I promise to keep in mind for future projects:

  • Digital methods are technological assemblages. The higher the number of moving parts, the higher the instability of the assemblage. Especially if the components are not governed by open standards.
  • Who’s accountable? Some platforms support developers and encourage the development of third party applications. Some others are only accountable to their users. Some others only to their customers. Some others only to their shareholders. Therefore, think twice before you decide which platform to investigate (and how).
  • Open. As a platform, the more open you are to third party applications, the more you can benefit from the (free) labour performed by amateur, tinkerer and researchers. Easy to use and free API make Twitter a convenient platform to investigate (although, their data are all but open and their API policies very shady). Based on the number of peer reviewed articles published, Twitter data are also the most utilized social media data.
  • Neutral. API are far from neutral tools, meaning that they can be seen as having ‘powerful consequences for the social activities that happen with them, and in the worlds imagined by them’ (Bucher, 2013)

Lastly, some readings particularly relevant and suggested to everyone working with commercial platform data and that warned me about the risks of working with platforms:

  • Snodgrass, E., & Soon, W. (2019). API practices and paradigms: Exploring the protocological parameters of APIs as key facilitators of sociotechnical forms of exchange. First Monday, 24(2).
  • Bucher, T. (2013). Objects of Intense Feeling: The Case of the Twitter API. Computational Culture (a Journal of Software Studies), 1–17. Retrieved from http://computationalculture.net/article/objects-of-intense-feeling-the-case-of-the-twitter-api
  • Steinberg M. (2019) The Platform Economy. How Japan transformed the consumer internet. Minneapolis, MN, University of Minnesota Press (read my review here)
  • Langlois, G., & Elmer, G. (2013). The research politics of social media platforms. Culture Machine, 14, 1–17.
  • Gillespie, T. (2018). Custodians of the internet: platforms, content moderation, and the hidden decisions that shape social media. New Haven: Yale University Press.
  • Gillespie, T. (2010). The politics of “platforms.” New Media & Society, 12(3), 347–364. https://doi.org/10.1177/1461444809342738

Photo by Steve Johnson from Pexels

Comments are closed.