USB cables are standard; real-time bus APIs need to be. Photo by osde8info on Flickr.

Why do some apps for getting bus predictions work with some DC-area bus services, like WMATA and the Circulator, but not others, like ART and Ride On? Why couldn’t the NextBus DC app just use the same data source that other apps do? Why is this all so complicated? The answer lies in APIs—application programming interfaces— and fragmentation.

Previously, we talked about how the NextBus DC app went away because they were getting their data from NextBus Information Systems, which lost its relationship with NextBus Inc., the company powering the WMATA bus tracking web and phone tools known as NextBus.

The plethora of things called NextBus aside, my first question when the NextBus DC app went down was, why can’t they just reconnect their app to a data source that isn’t broken? If the bus locations still exist, and the bus predictions still exist, and there’s nothing wrong with the app’s code itself, we should look at why it’s not easy for them to simply bypass the broken link in the chain.

To understand what’s going on, we have to delve a little more into APIs. An API, or application programming interface, is a way for one computer program to contact another computer and get certain information directly, in a structured format, without a human having to be involved.

For example, Twitter has an API, and if you’re writing a software program that accesses Twitter, you can have it talk directly to Twitter to post tweets, search tweets, and so on. I put code on the Greater Greater Washington system so that when a post goes live, it also automatically posts a tweet that the author or editor have written ahead of time, without a human having to go onto the website and click around.

Each API has a certain vocabulary. The asking computer users certain terms, and gets back data in a certain format. Other APIs have different words and different formats. If one API breaks but there’s one using the same vocabulary and formats on another system, it’s trivial to just have the app connect somewhere else. If the API is different, the software writer has to redo the code, maybe just a little, or maybe quite a lot.

NextBus DC app was not using the “official” API

WMATA contracts with NextBus Inc. to run the bus prediction section of wmata.com and a text message and phone service, but not for an API. For other systems that contract with NextBus, it also offers an API for developers as part of its package of services. However, that is not available for WMATA Metrobus predictions.

A few years ago, WMATA embarked on a pretty ambitious project to offer all kinds of data, including bus predictions but also rail predictions, rail station locations, bus stop locations, schedules, elevator outages and more. Because they have this service, said WMATA spokesperson Dan Stessel, they have asked NextBus not to offer its own, different API.

However, that NextBus API is actually what the NextBus DC app was using, because of the legacy agreements between NextBus Inc., NextBus Information Systems, and AppTight. When those expired, that API went away. AppTight could have probably redone its app to use the WMATA API, but that would not have been an easy task.

Is WMATA right not to let NextBus use its own API? There are definitely some valid reasons for this. Stessel explained that if WMATA let app developers use the NextBus API and then WMATA decided to end its contract with NextBus, all of those apps would break. Plus, there is a lot of other information in the WMATA API, so people building apps on the WMATA API would find it very easy to also show next train arrivals, for instance, while anyone using the NextBus API couldn’t.

We need standardization

API formats are particularly important because there are a lot of transit agencies, across different cities and even within our region. If they use incompatible APIs, then it’s difficult for app writers to support all of them, and smaller bus systems get left out.

The bigger the potential audience who might pay a buck or two for an app, the more app developers will build transit apps. If they can build one app and have it help riders in DC, New York, Chicago, Los Angeles, etc., that’s a lot more incentive to build something than if it just works for one city. Small cities especially benefit here, because not as many people will want to build an app for the bus system in Charlottesville, but if the Chicago app works for Charlottesville too, great.

The same logic applies to bus systems here. Some apps work with the WMATA API but don’t support any of the regional bus systems. The DC Metro Transit Info app has Metrobus and also supports Circulator, Fairfax CUE and PG The Bus, all of which work with NextBus and support the NextBus API. ART and Ride On have real-time APIs, but they’re not the WMATA or NextBus APIs, and the author of DC Metro Transit Info hasn’t done the extra work to integrate those as well.

What needs to happen is that all transit agencies and app developers need to coalesce around one API format. WMATA should modify its systems to offer apps the option of making their requests and getting data back in this standard format. So should NextBus. So should ART and its provider, Connexionz, and Ride On, and New York MTA, and Chicago CTA, and everyone else.

It’s similar to power chargers for cell phones. Once, every phone had a different plug. You had to use a special charger just for that phone, and if you got a new phone, your old chargers were junk. Now, almost everyone except for Apple use micro-USB, and all the chargers for my 2½-year-old Android phone work on my brand new one as well.

Fortunately, WMATA is open to changing its API to a standard. Stessel said,

Over the course of the next six months, we will be reviewing our API effort in full, and determining ways to improve the service. Standardizing the format is a definite consideration. However, current applications must be taken into consideration… Short answer: Yes, it is something that is being considered.


If WMATA just switched its API, all existing applications would break, just like NextBus DC did. They could simply offer 2 APIs, but for how long? It creates extra work to have to maintain multiple APIs far down the road. They could switch APIs and offer both for a transition period, perhaps a year, but no matter what some apps won’t make the switch.

There’s a big obstacle to all agencies moving to a standard API, however: it’s not yet clear what the standard should be. If the USB of real-time bus data is out there, there isn’t the consensus around it. In upcoming parts, we’ll talk more about the API standards that exist today.

Plus, having a standard API is great, but it’s useless if the actual bus locations are not good, and many say WMATA’s data is just not up to snuff. We’ll talk about that and their efforts to fix the problems with bus tracking.

David Alpert is the founder of Greater Greater Washington and its board president. He worked as a Product Manager for Google for six years and has lived in the Boston, San Francisco, and New York metro areas in addition to Washington, DC. He lives with his wife and two children in Dupont Circle.