Jefry Cruz
The problem with raw walkability data
The underlying data exists. The U.S. Census Bureau publishes pedestrian infrastructure estimates. The EPA publishes Smart Location Database metrics. NHTSA publishes crash data. The problem is that each of those datasets arrives with its own schema, its own geographic identifier system, and its own update cadence.
Joining a TIGER/Line shapefile to an ACS table to a crash file is a multi-day project before you write a single line of product code. You'll wrestle with FIPS codes that don't match ZIP codes, vintage years that don't align, and geometries that need reprojection. That's real engineering work, and it has nothing to do with the feature you're actually trying to ship.
Most developers don't need to own that pipeline. They need a number they can render.
What the API actually returns
A single GET or POST to /v1/address returns a JSON object with eight scores on a 0, 100 scale: walkability, bikeability, safety, schools, family, density, affordability, and nightlife. The same response includes raw demographics, housing, schools, crime, health, hazard, and mobility data, all normalized from federal sources: the Census Bureau, FBI, NCES, EPA, and NOAA.
Coverage is 33,142 ZIPs, counties, and states across 58 endpoints in 14 domains. Cached p50 latency is 19ms. The other geographic inputs (/v1/zip, /v1/county, /v1/state) follow the same response shape.
One thing worth saying plainly: these scores are derived from public data and reflect what that data shows. A rural ZIP will score low on walkability because the infrastructure and transit data say so. There's no editorial adjustment. If your users will see the scores, that framing is worth passing along to them.
A minimal integration
No SDK required. Here's a fetch call in JavaScript:
const res = await fetch(
'https://api.atlasblock.dev/v1/address?address=1600+Pennsylvania+Ave+NW+Washington+DC',
{ headers: { 'Authorization': 'Bearer YOUR_API_KEY' } }
);
const data = await res.json();
console.log(data.scores.walkability); // 0–100
That's the shape of it. Parse data.scores.walkability and you have something you can render in a card, a tooltip, or a filter. The full endpoint reference is in the docs if you need query parameters, response field names, or error codes.
The free tier is 1,000 calls per month with no credit card required. You can finish a prototype and decide whether this fits your product before you commit to anything.
All plans are hard-capped. No overage charges, ever. For a side project or an early-stage product, that matters. A traffic spike shouldn't become a billing incident.
When Atlasblock is the right fit, and when it isn't
It's a good fit if you're building a real-estate search tool, a relocation app, a rental listing site, a neighborhood comparison feature, or any product where U.S. neighborhood context helps a user make a decision.
It's not the right choice in a few specific situations:
- You need international coverage. The API is U.S.-only. Full stop.
- You need real-time data. Scores are derived from public datasets with their own update cadences, not live sensors or continuous feeds. If you need live pedestrian counts or real-time transit status, look elsewhere.
- You need a white-glove data licensing agreement. Atlasblock is a self-serve API. There's no enterprise contract negotiation.
For international coverage or custom licensing, Google's Places API and Precisely both cover different ground and are worth evaluating on their own terms. They solve different problems.
Scores versus raw data: know which one you need
The eight scores are fast to display and easy for end users to read. But they're a summary. A walkability score of 71 doesn't tell a user whether the gap is about transit frequency, sidewalk coverage, or intersection density. It just tells them the score.
The raw endpoints do tell them that. If your product needs to explain a score, or let users filter on specific dimensions (say, homes within half a mile of a school rated above 8), the raw fields are what you want. They're in the same response object, and they're available on every plan.
That second point is worth making explicit because tiered feature access is common in this category. With Atlasblock, every endpoint and every feature is included on the free tier. You don't unlock raw data by upgrading. You upgrade for call volume.
Check the pricing page to verify plan limits and costs yourself. Plans run from free (1,000 calls/month) to $349/month for 1,000,000 calls.
Putting it together
The build path is straightforward. Pick your geographic input type: address, ZIP, county, or state. Call the relevant endpoint. Map the scores or raw fields to your UI. Handle the 404 gracefully for addresses or ZIPs the API doesn't recognize, because not every input will match.
The API is versioned under /v1. When upstream data sources update, your integration won't break silently. You'll get a versioned changelog rather than a schema surprise.
One honest caveat before you ship: because scores are derived from public datasets, they inherit whatever gaps or lags exist in those source datasets. The Census Bureau's ACS estimates carry a one-year lag. NCES school data updates annually on a delayed schedule. If your product surfaces these scores to users, consider telling them what the data vintage is. Something as simple as "based on data through [year]" sets the right expectation and builds more trust than a score with no context.
That's the full picture. Public data is cleaned, joined, normalized, and served through a single versioned JSON API. You get eight scores and the raw data behind them, hard-capped plans, and 19ms cached latency. Build the feature, not the pipeline.
Get your free API key and make your first call at Atlasblock.
Sources
- U.S. Census Bureau – TIGER/Line Shapefiles checked
- EPA – Smart Location Database checked
- U.S. Census Bureau – American Community Survey checked
- NCES – National Center for Education Statistics checked
- FBI – Crime Data Explorer checked
- NOAA – National Oceanic and Atmospheric Administration Data checked