"Offender and crime API" describes two completely different products, and teams routinely start building one when they needed the other. One answers questions about a person: does this individual have a criminal record? The other answers questions about a place: how much crime happens here, of what type, and is it rising? The data sources, the coverage characteristics, and the legal obligations are unrelated. Getting the distinction right on day one saves a rebuild later.
Two different questions
| Person-level | Place-level | |
|---|---|---|
| Question | Does this individual have a record? | What is the crime profile of this area? |
| Typical use | Screening, vetting, onboarding, compliance | Risk scoring, site selection, research, underwriting |
| Sources | Courts, corrections, registries, exclusion lists | FBI UCR/NIBRS, agency open-data portals |
| Granularity | Individual, jurisdiction by jurisdiction | Agency, city, county, sometimes block |
| Latency | Days to months behind the event | Months to over a year behind |
| Regulation | FCRA, EEOC, state fair-chance law | Generally none — it is aggregate public data |
Person-level data is regulated the moment you use it to decide something about a person. Place-level data almost never is. Do not let one API surface both without separating the governance.
Criminal records APIs: where the data actually lives
The single most expensive misconception in this space is that there is a national criminal database you can query. There is not one available to you. The FBI maintains national systems, but access is restricted to law enforcement and to specifically authorized noncriminal-justice purposes, generally routed through approved channelers under statutory authority. If you are building a commercial product, you are not querying it.
What exists instead is a set of partial sources:
Court records APIs
Criminal cases are filed and disposed in county and state trial courts. This is the authoritative record, and it is also the most fragmented: thousands of courts, wildly varying online availability, and many jurisdictions still requiring in-person retrieval. Federal cases live in PACER, which is fee-based and offers no free bulk API; the Free Law Project's CourtListener and RECAP provide API access over the federal documents they have collected.
Serious screening providers run county-level searches precisely because the aggregated products miss cases. Depth costs money and time — that is the entire trade.
Inmate and corrections data
Most state departments of correction publish inmate and offender lookups covering current and former inmates, and the federal Bureau of Prisons publishes an inmate locator. Coverage is limited to people who were incarcerated in that system — no jail-only sentences, no probation-only dispositions, and typically no charges that did not result in a prison term.
Arrest and booking records
County sheriffs publish booking logs, and vendors aggregate them. This is the fastest-moving source and the most dangerous one to use naively: an arrest is not a conviction, booking records frequently never receive a disposition update, and reporting non-conviction information is restricted under the FCRA and prohibited outright for employment purposes in a number of states.
Registries and exclusion lists
Sex offender registries, state abuse and neglect registries, nurse aide registries, the OIG List of Excluded Individuals and Entities, and SAM.gov exclusions are all separate systems with separate rules. They are status lists, not criminal histories — presence means a specific administrative or judicial finding was made, and absence means very little. The registry layer is usually the easiest of these to cover well, because a single nationwide sex offender search API can replace fifty-odd separate state integrations — the criminal-history side has no equivalent shortcut. For how to evaluate that layer, see choosing a sex offender registry API.
The coverage math
Crime data APIs: FBI, NIBRS and open data
If the question is about geography rather than a person, the sources are better structured and largely free.
- FBI Crime Data Explorer. The FBI publishes national crime data through the Crime Data Explorer, which exposes an API for programmatic access using a key issued through the federal API key service. It covers agency-level offense, arrest, and related data drawn from the national collection program.
- NIBRS. The FBI transitioned its national collection to the National Incident-Based Reporting System, which captures incident-level detail — multiple offenses per incident, victim and offender characteristics, relationships — rather than the older summary hierarchy. It is far richer than the legacy summary data.
- Municipal open data. Many large cities publish incident-level feeds on Socrata or ArcGIS platforms, often updated daily and geocoded to block level. This is the only place to get genuinely recent, fine-grained data.
Two caveats that determine whether your analysis is sound:
- 1Reporting is voluntary and incomplete. Participation in national collection varies by agency and by year. The NIBRS transition in particular changed which agencies were reporting, so year-over-year comparisons across that boundary can show movement that is an artifact of participation rather than of crime.
- 2These are reported offenses. They measure what was reported to and recorded by police, which is not the same as what occurred. Categories with low reporting rates are systematically understated.
What an offender API actually returns
Whatever the source, expect to build a normalization layer. There is no shared schema across person-level providers, and the fields you most want are the ones most often missing:
- No universal person identifier. Matching is name plus date of birth plus whatever else you have. Same problem as registry data, same mitigations.
- Dispositions are frequently absent. A charge without an outcome is the most common defect in aggregated criminal data, and it is the field that determines whether the record is usable at all.
- Offense descriptions are free text. "Theft," "larceny," "TOL," and a bare statute citation may all describe the same thing. If you need severity or category, you are building that mapping yourself.
- Sealing and expungement lag. A record cleared by a court can persist in an aggregator's snapshot. Where you are acting as or through a consumer reporting agency, the FCRA requires reasonable procedures to assure maximum possible accuracy, and separately limits the reporting of certain non-conviction items after seven years.
Architecting a background screening pipeline
The shape that holds up in production, independent of which vendors you pick:
- 1Canonical subject record. One normalized identity — legal name, aliases, prior names, date of birth, address history — built once and reused for every query. Sources disagree; your representation should not.
- 2Fan out, don't chain. Registries, criminal search, exclusion lists and abuse registries are independent queries. Run them concurrently and collect results; sequencing them is the difference between seconds and minutes. Prefer sources that answer synchronously — a sex offender search API that returns scored, deduplicated results in one call keeps the whole fan-out inside a request cycle, while a county court search that takes days has to be modeled as an async step from the start.
- 3Score, don't decide. Every hit carries a confidence and the fields that produced it. The system's output is a reviewable finding, never an automated denial.
- 4Route to a named adjudicator. Hits go to a human with a defined SLA and a documented standard. Who reviewed it and on what basis is the record that matters if the decision is ever challenged.
- 5Retain the raw response. Store what each source returned, with timestamps and source identity. Disputes are unwinnable without it.
- 6Re-screen on a schedule. A check is a point-in-time snapshot. Exclusion lists in particular are updated on a regular cadence and are commonly re-screened monthly; a single pre-hire check leaves the rest of the employment relationship uncovered.
FCRA and fair-chance compliance
If any part of this influences a decision about employment, housing, credit, or insurance, you are in FCRA territory and the obligations are procedural and specific: permissible purpose, standalone disclosure and written authorization, pre-adverse action notice with a copy of the report and the summary of rights, a reasonable waiting period, and a final adverse action notice. Separately, EEOC guidance disfavors blanket criminal-history exclusions and expects an individualized assessment weighing the offense, the time elapsed, and its relevance to the job. State and local fair-chance laws add timing rules, lookback limits, and restrictions on non-conviction data that vary by the location of the role.
None of that is optional because you built the integration yourself rather than buying a screening product. The obligations attach to the use, not to the architecture.
The healthcare application
In post-acute care this stops being theoretical. Facilities screen employees, contract and agency staff, and vendors — and they also need screening at resident intake, where a referral must be checked against registries and exclusion lists before a bed is offered. The two flows use overlapping data sources under different legal frameworks, which is exactly the distinction this article opened with.
The operational failure mode is not usually a missing data source. It is inconsistency: the check that got skipped on a busy Friday, the agency nurse nobody screened, the annual re-screen that slipped to eighteen months. Running the full set automatically on every referral and every worker, with a retained audit trail, is what automated compliance screening is for — and it is the part that survives an audit.