On Our API | Are.na Editorial
Main Channel: On Our API<br>References: API Developer Meetup (4/30/26), Damon Zucconi, Publishing as Side Effect, Powered by Are.na, and Are.na API V3 Wishlist<br>Category: Hello WorldAll Editorial
On Our API
May 29, 2026 — by Charles Broskoski<br>Are.na Profile
[A diagram that looks like an org chart of family tree, populated with differently-colored squares.]
We recently made a major version update to our API (v3), the first major update in over ten years.<br>A few weeks ago, we celebrated this with an API / Developer meetup at Index Space in New York. The idea was to showcase the new structure and discuss some brand new functionality (more on this in a bit). We also wanted to give space for people to demo their own projects using Are.na’s API, which we’ve noticed a significant uptick in recently.<br>Before the meetup, Damon and I talked for a while to figure out what we were going to say in our presentation. I suggested that to prepare we could just talk about the API in general and record it. I wanted to see if we could unearth anything useful by examining our thoughts on why it’s important to have an API and what is particularly special about ours.<br>One realization we came to is that we’ve always considered our API to be an elemental aspect of Are.na, in part because it’s a concrete way to articulate an important philosophical aspect of Are.na: that it should preserve space for latent potentiality.<br>In other words, it’s important for Are.na to have an API because it’s important for Are.na to be open. We don’t want to be prescriptive about what Are.na should be used for, so over time we’ve tried to make all of the core operations as smooth, ergonomic, and performant as possible. All the work we do on Are.na itself has to do with improving, refining, and (in rare cases) adding on to this core set of functionality, in service of maintaining the beautiful dynamic on Are.na that we’ve all been privileged to participate in.<br>As a result of this, the people who use Are.na also have more of a hand in defining it and our API is a surface that allows the people who use Are.na to actively re-interpret it. Now (like our web client and iOS app), it’s finally getting the update it deserves.<br>Some background<br>For anyone unfamiliar with the term API, it’s essentially just a set of rules for one piece of software to talk to another. For example, instead of interacting with Are.na through a website or a mobile app, one could make their own little program that uses Are.na data in a different way. You could use the Are.na API to display a channel as a screensaver, or use it to make a portfolio website, or use it to show blocks in a chat-like interface. The possibilities are literally endless.<br>When we started Are.na nearly 15 years ago, it was pretty standard for popular services to have an API (just like nearly every service at the time had an RSS feed). There was a lot of talk about the idea that web services could be interoperable, that the web consisted of building blocks that people could arrange in whatever ways they saw fit. That software, ideally, should be open source. That people should (lol) learn how to code. This was the ethos of the time that we grew up in, as engineers.<br>At the time, we took inspiration from some of these ideas and focused on the notion that what we were building was, at its core, just a system of primitives: Blocks are content, Channels are containers, and Connections are what link the two together.<br>In the beginning, Are.na was a single monolithic Rails application — meaning the data, the business logic for storing the data, and the logic for the display of the data all lived in the same place. This was also standard for the time. Eventually, we realized that we could separate the front-end from the back-end and gain a new surface in the process: an API that other people besides us could use.
[A photo of a computer screen with a browser opened to a webpage with a white background and black type: “a website that uses the are.na API as CMS.”]
It was only after building it that we realized what an interesting dynamic we were uncovering. Because blocks and channels map very cleanly to something like “content” and “containers,” there was a whole set of things you could use our API for that were much more useful than a typical social network’s API. It was something like a social version of a CMS.<br>We were already used to the idea that content on Are.na has a life of its own. At any given point, a block you added could be connected to a different channel, giving it additional context, and allowing it to be seen in a different way. Through our API, content on Are.na is given the additional potential to live outside the platform itself. Damon called this “publishing as side effect.”
[Screengrab of a Tweet by Virgil Abloh that reads: the process is the practice. the artifacts are just the side effects.]
Projects Using Our API<br>If you ever used our old API, you’ll have noticed that it...