Imagine a citizen is selling a condo in Chicago. She finds a great buyer, the process goes smoothly, and when she's ready to take care of the details, she taps into the city’s app, pays the portion of the property transfer tax owed, requests and downloads a Full Payment Certificate indicating up-to-date utility payments, and updates the deed of ownership with the recorder’s office.

That streamlined process may seem like a reach, but it’s possible today. In a city operating with a unified API for its government systems, this could be reality.

Before I go into how, let’s take a step back and consider the various government entities that would be involved in the scenario I outlined above:

1. The tax division of the Department of Finance, which handles the transfer tax.
2. The utility billing and customer service division of the Department of Finance, which verifies payment status for water and other utilities.
3. The recorder’s office, which handles deed recording.

Today, most of us live in cities and towns where doing everything mentioned above would take at least a week, and possibly longer. We’d have to either hunt down information on multiple disconnected websites or actually go into government buildings to submit paperwork.

But it doesn’t have to be this way.

Cities in silos

In the days when everything happened on paper, we learned to expect government processes to be slow and painful. After all, governments are mostly in the business of transferring money, granting permissions and enforcing regulations for individuals, groups, and businesses.

Those roles require high levels of detailed work: verifying information in permits, ensuring that basic math is done correctly, cross-referencing addresses with zoning lines.

As our digital capabilities grew, cities modernized their systems: first, internal digital databases were able to store and process information more efficiently. Then, we saw many city functionalities move online. Today, we’re in a place where most state and city departments have a website and allow citizens and businesses to carry out certain activities online.

But most of those systems don’t talk to each other.

What this looks like day to day is that we have to enter our information over and over on multiple websites when we want to carry out government-related tasks. We may have to remember dozens of passwords to log in to secure portals where our data is stored.

With a unified API, though, that problem is solved.

How a unified API helps government agencies talk to each other

APIs – application programming interfaces – are ways to link two or more existing systems and enable them to do more than just their constituent parts. A unified API overlays discrete systems and translates data from them into a common language. It wraps around existing technology to create standard data output.

When we apply this to cities, the result is something like the scenario I described earlier: government becomes an almost invisible system of support, rather than a cumbersome obstacle. Data can be shared in a smooth, streamlined way among agencies so citizens can get more done, more quickly.

And while I offered one specific instance of what life might look like in a city that uses a unified API, the benefits of implementation are many.

Unified APIs can:

• Enable a single digital destination for all government-related tasks (voter registration, car registration, tax payment, etc.).
• Facilitate proactive, hyper-targeted communication about important events, outages, planned work, road closures, weather alerts, and more.
• Improve the efficiency of payment systems, letting people more easily submit, track, and review payments for services, fines, licenses, and more.
• Streamline licensing, permitting, and registration processes for businesses.

But maybe the most compelling reason to push our governments toward adopting unified APIs is that they are built to adapt. They’re built with the understanding that government and the way we want to interact with it will evolve as the technology available to us evolves. They’re built not to provide an up-to-the-second solution for exactly what we can do today, but to accommodate an evolving landscape of capabilities and needs.