The Developer's Guide to Free Crime Data APIs

Every few months, a developer posts to a forum asking the same question: where can I get free crime data for my app? The answers they get back are usually incomplete. The public crime data landscape is bigger — and more complicated — than most people realize.

The question surfaces regularly in developer communities. A recent thread in r/node asked exactly this: how do you access crime data for free via API? The responses pointed in several directions — some useful, some outdated, some wildly optimistic about what “free” actually means when it comes to production-grade data. This post is the answer that thread deserved.

There are legitimate, well-maintained public crime data APIs available today. The U.S. Department of Justice publishes several. The FBI has its own developer portal. The United Kingdom runs one of the most developer-friendly police data APIs in the world. Each is worth understanding — both for what it offers and for where it breaks down.

The DOJ Developer Portal: Three APIs Worth Knowing

The U.S. Department of Justice maintains a developer resources page at justice.gov/developer that most developers have never seen. It hosts three APIs relevant to anyone building with crime data.

The FBI Crime Data API is the most comprehensive. It exposes the UCR (Uniform Crime Reporting) program data — both the legacy Summary Reporting System (SRS) and the newer National Incident-Based Reporting System (NIBRS). NIBRS is the more powerful of the two: it captures incident-level data including offender and victim demographics, the relationship between parties, weapon types, and incident timing. For researchers building models or analysts exploring longitudinal trends, the FBI Crime Data API is genuinely powerful. It returns JSON and CSV, and a registered API key is free.

The National Crime Victimization Survey (NCVS) API, maintained by the Bureau of Justice Statistics, is a different type of source entirely. Rather than measuring reported crimes, the NCVS is a household survey — roughly 240,000 persons interviewed annually — designed to capture victimization that never made it into police records. It's the federal government's primary attempt to measure the gap between what happens and what gets reported. For applications dealing with risk modeling or policy analysis, this is a valuable complement to incident data.

The CrimeSolutions Programs APIis narrower in scope — it catalogs evidence-based criminal justice programs evaluated by the National Institute of Justice. It's less useful for location-based safety applications but relevant for platforms serving policy, academic, or grant-making audiences.

The FBI Crime Data Explorer: Power and Patience Required

Sitting on top of the FBI Crime Data API is the FBI Crime Data Explorer(CDE), located at cde.ucr.cjis.gov. It's a web application that lets researchers and developers explore UCR and NIBRS data visually before pulling it programmatically — useful for validating what's available for a given jurisdiction before writing a single line of API code.

The CDE is genuinely impressive in scope. You can query by offense type, agency, state, year, and demographic breakdown. NIBRS data, where available, goes down to the incident level. For journalists, academics, and policy researchers, it's one of the most powerful free public tools in existence.

But the CDE has a fundamental constraint that makes it unsuitable as a backend for most consumer or commercial applications: the data lags. Annual UCR data typically arrives 12–18 months after the reference year. NIBRS is faster in theory, but in practice the CDE doesn't surface data in anything approaching real time. If you're building a safety app that tells a user whether their neighborhood has been experiencing elevated crime over the past 30 days, the FBI's data simply can't answer that question.

There's also the coverage problem. NIBRS participation, while growing, is still not universal. During the 2021 transition year when the FBI moved away from the SRS legacy system, major agencies including the NYPD failed to submit entirely. The resulting gaps in the national record are significant enough that criminologists have issued public warnings about using 2021 data for trend analysis. A production app that depends on the FBI API needs a fallback strategy for missing jurisdictions — and that strategy almost always involves a secondary data source.

The UK Police API: The Gold Standard for Open Crime Data

If the U.S. federal APIs are the pragmatic choice, the UK Police API at data.police.uk is the aspirational benchmark. It is, by a significant margin, the most developer-friendly government crime data API in the world.

The API offers street-level crime data, outcomes by case, stop-and-search records, and neighbourhood-level information — all returned as standard JSON over HTTP GET and POST. Spatial queries work by coordinates or radius. You can query crimes at a specific location, crimes within a custom polygon, or crimes aggregated by neighbourhood. The response schema is clean and consistent across forces. There are no obscure field names inherited from 1980s mainframe databases. It just works the way a modern API should work.

The UK Police API covers 43 territorial police forces across England and Wales. Authentication is not required for most endpoints, though rate limits apply. It's genuinely one of the best-documented, most usable government data APIs of any kind — not just in the crime data category.

The limitation is obvious: it only covers the UK. If you're building anything for a US audience, you're looking at a different problem entirely. But the UK Police API is worth studying as a design reference — it demonstrates what well-structured, openly published crime data can look like when a government treats developer experience as a real priority.

Why Free APIs Break Down in Production

Here's the honest answer to the developer asking that forum question: free public crime data APIs are excellent for research, prototyping, academic work, and building proof-of-concept tools. They are genuinely useful, and you should know about them. But they have a consistent set of failure modes when you try to build a production app on top of them.

Timeliness. The FBI and DOJ APIs reflect annual or at best quarterly data. For any application where recency matters — a rental platform showing safety scores, a family safety app sending neighborhood alerts, a corporate security tool assessing site risk — 12 to 18 months of lag is unusable. Users expect to know what happened last week, not last year.

Coverage gaps. No public API covers every US jurisdiction consistently. Agency participation in federal reporting programs is voluntary. Reporting quality varies dramatically by department. Some cities submit detailed NIBRS data promptly; others send summary-level SRS data months late; some miss submission windows entirely. Building a product that promises nationwide coverage on top of these gaps is a reliability problem waiting to surface.

Normalization.Different jurisdictions classify the same crime differently. An armed robbery might appear as “robbery with a dangerous weapon,” “aggravated robbery,” or simply “robbery” depending on the department. Before you can display a coherent crime feed to an end user, someone has to normalize those classifications into a consistent taxonomy — and that normalization work is expensive to build and maintain.

Address-level resolution. Federal APIs operate at the agency, county, or state level. Getting incident data mapped to a specific address — the block where a property is located, the intersection a commuter passes through — requires a different infrastructure layer entirely.

Where SpotCrime Fits In

SpotCrime.comhas been aggregating crime data from police departments across the US and internationally for nearly two decades. It's a public-facing crime map and alert service used by more than 5 million people — the consumer layer where someone checks what's happening near their home or signs up for neighborhood alerts. It's the proof of what the underlying data infrastructure can do when surfaced for a general audience.

SpotCrime.io is that same infrastructure opened as an API for developers. The core data pipeline ingests incident reports from law enforcement agencies covering 22,000+ US cities, normalizes crime classifications across jurisdictions, geocodes incidents to address level, and makes the result queryable in real time. Rather than building and maintaining that pipeline yourself — a project that took SpotCrime years to get right — developers can query it directly.

The difference between the public APIs and SpotCrime's API comes down to three things: recency (updated continuously rather than annually), resolution (address level rather than agency level), and normalization (consistent crime taxonomy rather than raw departmental classifications). For research and historical analysis, the DOJ and FBI APIs are excellent and free. For production applications where users expect current, precise, reliable data, the free tier runs out quickly.

neighborhood safety score, SpotCrime's neighborhood safety rating system, is a downstream product of this same data — a normalized score that incorporates crime frequency, type weighting, recency, and 36-month trend direction for any US address. It's designed for exactly the use case where a real estate platform, insurance model, or family safety app needs to present a safety assessment without exposing raw incident feeds to an end user.

The Practical Decision Framework

If you're a developer evaluating crime data options, here's how to think about it:

• Research, journalism, policy analysis: Start with the FBI Crime Data Explorer and the DOJ developer APIs. They're free, well-documented, and deep enough for most analytical work. The UK Police API is worth using if your scope includes England and Wales.
• Prototyping a US safety application: Use the FBI API to validate your data model and understand what fields matter. But plan for the transition to a real-time source before you go to production.
• Production consumer or commercial application: You need recency, address-level resolution, and consistent coverage. That combination doesn't exist in the free public APIs — not because the government is withholding data, but because building that infrastructure is genuinely hard and expensive.
• Real estate, insurance, family safety, corporate security: These use cases require normalized scores and trend data in addition to raw incidents. neighborhood safety score is built for this.

The forum question — where can I get free crime data for my API — has a real answer. The DOJ developer portal at justice.gov/developer, the FBI Crime Data Explorer at cde.ucr.cjis.gov, and the UK Police API at data.police.uk are all legitimate, maintained, and worth your time. Know what they are, know what they can do, and know where they stop being enough for what you're building.