I Built the Census API I Wanted to Use
By Andrew Britt
PrairieCloud started with a simple reaction: this data matters too much to be this hard to use.
There is a predictable moment in almost every project that touches U.S. Census data.
You start with a normal question.
What is the population of Travis County, Texas? How has median household income changed over time? Which census tracts in a metro area qualify for a given analysis?
You assume this will be straightforward, because the Census Bureau has an API and the data is public.
Then you actually try to use it.
You find out that total population is called B01003_001E. You learn that a place you think of as “Travis County, Texas” needs to be translated into state:48 and county:453. You discover that the response comes back as an array of arrays, with the header row embedded in the payload, which means every request starts with a little cleanup job before you can do anything useful.
None of this is impossible. It is just friction everywhere.
And the friction adds up.
The variable names are cryptic. The geography model is harder than it needs to be. The format assumes you are willing to do a bunch of translation work before you even get to your real task. If you need boundaries for a map, that is another pipeline. If you need tract-level work, that is another layer of complexity. If you are building something real, you end up spending a lot of your time adapting to the data source instead of building with the data.
That was the reason I started PrairieCloud.
Not because the Census Bureau data is bad. The data is incredibly valuable. It tells you how communities live, change, struggle, and grow. It helps people build products, run research, allocate resources, evaluate policy, and make lending and investment decisions.
The problem is that too much of that value is trapped behind an interface that feels like it was designed for people who already know all the answers.
The problem is bigger than developer annoyance
If this were only a matter of developer ergonomics, it would still be worth fixing. But it is not only that.
When public health teams work with Census data, they are often trying to answer questions that affect real people. Where are the most vulnerable neighborhoods? Which communities have the weakest access to transportation, housing stability, or health insurance coverage? Where should outreach or funding go first?
When community development lenders use Census data, they are trying to determine whether a tract qualifies for CRA-related work, or whether a market fits the constraints of a program.
When civic technology teams use Census data, they are building tools that help ordinary people understand the places they live.
In all of those cases, the challenge should be the analysis itself. It should not be decoding variable names, stitching together identifiers, downloading separate boundary files, or explaining to a teammate why the API returned a spreadsheet-shaped JSON response.
That mismatch kept bothering me.
We have some of the most important public datasets in the country. They should be easier to work with than this.
So I built the API I wanted to use
The core idea behind PrairieCloud is not complicated.
Take the parts of Census data work that are repetitive, fragile, and needlessly opaque, and make them sane.
That means human-readable variable names.
That means geography resolution by name instead of forcing everyone to memorize or look up FIPS codes.
That means structured JSON responses that are ready to use.
That means modern API keys, usage dashboards, clear documentation, and examples written for developers who want to make progress, not earn a merit badge.
It also means treating boundaries as part of the workflow, not as a separate scavenger hunt. If you are building a map, you should be able to get the data and the geometry together.
Here is the difference in spirit.
Instead of starting here:
[["B01003_001E","NAME","state","county"],
["1290188","Travis County, Texas","48","453"]]
I wanted to start here:
import requests
response = requests.get(
"https://api.prairiecloud.io/v1/data",
params={
"variables": "pop_total",
"geo": "county:Travis County, Texas",
"vintage": 2024,
},
headers={"X-API-Key": "pck_live_your_key_here"},
)
print(response.json())
Or here:
curl "https://api.prairiecloud.io/v1/data?variables=pop_total&geo=county:Travis%20County,%20Texas&vintage=2024" \
-H "X-API-Key: pck_live_your_key_here"
And get back something that looks like it was made for software written this decade.
That is what PrairieCloud is trying to do.
A cleaner Census data API. A better geography model. A more usable response format. Boundaries when you need them. An MCP server when your workflow involves AI tools. Less translation, more building.
What PrairieCloud is today
PrairieCloud is a modern REST API and MCP server for U.S. Census data. It is running in production today, with Free and paid tiers available through the dashboard.
Today, the product includes 392 human-readable variables with Census code aliases, 7 geography levels, 35 ACS vintages, 901.6 million observations, GeoJSON boundaries, analysis-friendly endpoints like compare and time series, and MCP access for AI workflows on paid tiers.
It is built for developers, analysts, GIS workflows, and technical teams who need Census data in production, not as a one-off research detour.
The point is not to hide the source. The point is to make the source usable.
If you want the original Census code, you can still use it. If you already know your FIPS codes, great. If you want to work by county, tract, metro area, or congressional district name, you should be able to do that too.
If you want data for a choropleth, you should not have to juggle three separate systems before you can render your first map. PrairieCloud treats boundaries as part of the workflow; inline GeoJSON, wildcard expansion, and boundary access vary by tier, but the model is the same: data and geography belong together.
And if you are evaluating tools for a team, pricing, limits, and capabilities should be explicit. Hidden quotas and vague “contact us” pages make technical evaluation harder than it needs to be.
That level of clarity should be normal. In this category, it usually is not.
The weird part: how the company is built
There is one unusual part of this story.
PrairieCloud is bootstrapped, and I have been building it with a small AI-supported team running on OpenClaw.
That is not the product pitch. Nobody needs another “we used AI” story if the software does not solve a real problem. But it does matter for one reason: products like this usually do not get built.
A modern Census data API is valuable, but it is also niche. It sits in the awkward zone where the problem is real, the users care a lot, and the traditional startup logic says it is too specialized to be interesting.
I think that logic is getting weaker.
When the cost of building and operating software drops, more useful “too small” products become viable. That is good for founders, and it is good for users with specialized problems that have been ignored for years.
PrairieCloud exists because I think Census data deserves a better developer experience, and because the economics of building a company are finally making that kind of product practical.
Who this is for
PrairieCloud is for the developer who has already spent one afternoon too many wrestling with Census table codes.
It is for the analyst who wants tract-level inputs for a model without spending half the day cleaning up extraction logic.
It is for the GIS developer who wants data and boundaries in one workflow.
It is for the team building a civic app, a lending workflow, an internal analytics tool, or an AI-powered experience that needs demographic context.
It is not trying to be a visualization platform. It is not trying to be every government dataset at once. It is not real-time economic data.
It is a developer-friendly API for Census data.
That focus is deliberate.
Why I am writing this now
This is the first real post on the PrairieCloud blog, so I wanted it to do one thing well.
Not announce every feature. Not pretend we are bigger than we are. Just explain why this company exists.
The short version is this:
I kept seeing important public data made harder to use by avoidable interface decisions. I thought there should be a better way to work with it. So I started building one.
PrairieCloud is still early. That is part of the appeal, honestly. The product is running in production, the Free tier is open, and the feedback loop is short.
If you try it and something is confusing, I want to hear about it.
If you are building something with Census data and the current tooling keeps getting in your way, this is for you.
And if you have ever stared at B01003_001E and thought, “there has to be a better system than this,” I agree.
That is why PrairieCloud exists.
Start building with PrairieCloud →
Andrew Britt is the founder of PrairieCloud. He lives in Texas and is building developer-friendly infrastructure for U.S. government data.
Follow along: @prairiecloud.io on Bluesky, @PrairieCloudIO on X.