Best Sex Offender Registry API: A Buyer’s Guide

If you are trying to add a sex offender check to a hiring flow, a resident intake, or a marketplace onboarding process, the first thing to understand is that there is no single authoritative API to call. The United States does not have one sex offender registry. It has more than fifty of them, each with its own rules, fields, and refresh schedule. Everything that follows is a consequence of that fact.

How sex offender registry data actually works

The federal framework comes from the Sex Offender Registration and Notification Act, enacted as part of the Adam Walsh Child Protection and Safety Act of 2006. SORNA sets baseline standards for who must register, for how long, and what information jurisdictions should collect. But registration and publication are operated by the states, territories, and participating tribes — not by a federal agency.

In practice that means roughly fifty-seven separate public registries: the fifty states, the District of Columbia, the five inhabited U.S. territories — Puerto Rico, Guam, the U.S. Virgin Islands, American Samoa and the Northern Mariana Islands — and a set of participating tribal registries operating under their own SORNA implementations.

The practical consequences of a fifty-jurisdiction system:

• Not every offender is public. Jurisdictions tier offenders differently, and lower tiers are frequently excluded from public websites entirely. Juvenile adjudications are often non-public. A clean registry result means "not found in public data," never "no history."
• Fields differ. Some jurisdictions publish offense descriptions, statute citations, conviction dates, physical descriptors, vehicle information, and employment or school addresses. Others publish a name, a photo, and a city.
• Refresh cadence differs. Some registries update continuously; others publish on a batch schedule. An aggregator is only as current as its slowest source.
• Compliance status matters. Absconder, non-compliant, incarcerated and deported statuses are meaningful signals — and are exposed inconsistently.
• No shared identifier. Registries do not publish Social Security numbers. Matching is done on name, date of birth, aliases, and photographs.

Is there an NSOPW API?

This is the first question almost everyone asks, so it is worth answering directly. The Department of Justice operates the National Sex Offender Public Website (NSOPW, sometimes still called the National Sex Offender Registry or by its older Dru Sjodin name). It performs a federated, real-time search across participating jurisdiction registries and returns results from each — the closest thing to a national sex offender search that exists.

What it is not is a commercial data feed. NSOPW is built for public, one-off manual lookups. There is no general-purpose developer API with keys, rate limits, and an SLA, and building an automated screening product by driving a public search portal is fragile technically and questionable under the terms that portal is offered under.

A few properties of NSOPW that matter if you are planning around it:

• It queries, it does not store. NSOPW passes your search to each participating jurisdiction at request time. If a state registry is down or slow, those results are simply absent — and the interface does not always make the gap obvious.
• Participation is not universal. Jurisdictions choose to participate, and the set changes. Coverage is broad, not guaranteed complete.
• Results reflect each state's public policy. If a jurisdiction does not publish a tier of offenders on its own website, those offenders do not appear in NSOPW either.
• It is search, not screening. There is no confidence scoring, no deduplication across jurisdictions, no audit record, and no way to re-run a check on a schedule.

For a compliance officer doing a handful of lookups a month, NSOPW is the right tool and it is free. For anything that has to run on every applicant, every referral, or every onboarding — where you need scoring, deduplication, an audit trail and a response you can program against — you need a purpose-built sex offender registry API, which is what the three options below are about.

Three ways to get sex offender registry data

1. Go directly to official state registries

Some state registries publish downloadable datasets or offer structured endpoints. Going direct gives you the most authoritative data and the clearest provenance, and it costs nothing in licensing.

The cost shows up in maintenance. You are now operating fifty-plus independent integrations, each of which can change format without notice, and you own the normalization layer that makes them comparable. Teams that go this route almost always start with the handful of states they operate in rather than attempting national coverage on day one.

2. Buy from a data aggregator

Aggregators do the collection and normalization and expose one API. This is where most teams land. The trade you are making is convenience for opacity: you inherit the vendor's coverage gaps and refresh lag, and you usually cannot see either directly.

Note the regulatory distinction here, because it is the one that gets missed. A raw data aggregator is not automatically a consumer reporting agency. If you are using the results to make decisions about employment, housing, insurance, or credit, the use may bring the activity under the Fair Credit Reporting Act regardless of how the vendor describes its product. Confirm in writing whether your vendor is acting as a CRA for your use case, and if they are not, understand who is carrying that obligation.

3. Order through a consumer reporting agency

A background screening company acting as a CRA delivers registry results inside a compliant process: permissible purpose, applicant disclosure and authorization, dispute handling, and the pre-adverse and adverse action sequence. It is slower and more expensive per check than a raw API, and you get less control over the workflow.

For employment screening specifically, this is usually the correct default. The FCRA machinery is not optional, and building it yourself is a larger project than the integration that prompted the search for an API.

How to evaluate a sex offender API

Feature lists are close to identical across vendors. These are the questions that separate them:

It helps to have a reference point for what good answers look like before you start taking sales calls. A nationwide sex offender search API that publishes its jurisdiction list, returns a match confidence score with the basis for each match, and exposes per-source status so you can see which registries answered and which did not sets a useful bar — those are the properties that make results reviewable rather than merely deliverable.

Identity matching is the real problem

Registries publish names, not identities. There is no SSN, no driver's license number, no stable person key. So every check reduces to a fuzzy match on a name and, when you are lucky, a date of birth.

This produces two failure modes with very different costs:

• False positives. A common name matches a registrant who is not your applicant. Handled badly, this costs someone a job over a data artifact. Handled well, it costs a few minutes of human adjudication.
• False negatives. A name variation, a married name, a transliteration, a middle name in the wrong field, or a data-entry error hides a real record.

Practical mitigations that meaningfully improve match quality:

1. 1Search aliases and maiden names explicitly rather than relying on the primary name field.
2. 2Treat date of birth as a scoring signal, not a hard filter — registries carry DOB errors, and a hard filter converts them into silent misses.
3. 3Search across jurisdictions of residence history, not just current address. People move; registration follows them imperfectly.
4. 4Return the matched fields alongside the score so a human can adjudicate without reopening the source. "84% confidence" on its own is not reviewable.
5. 5Never auto-decide on a hit. Registry results are an input to a review, not a verdict.

FCRA, state law, and the limits on registry data

This is public-record data, which leads people to assume it can be used freely. That assumption is wrong in several specific and consequential ways.

• State restrictions on use. Several states restrict what registry information may be used for. California, for example, prohibits using data from its Megan's Law website to make decisions about employment, housing, insurance, credit, or benefits, and misuse carries penalties. A national screening product that ignores state-level use restrictions is not compliant just because the data was public.
• FCRA. When results are obtained through a consumer reporting agency for employment purposes, you owe the applicant a standalone disclosure and authorization before the check, a 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.
• EEOC guidance. Blanket exclusions based on criminal history can produce disparate impact. The expectation is an individualized assessment considering the nature of the offense, the time elapsed, and its relationship to the specific job.
• State and local hiring laws. Ban-the-box statutes, fair-chance ordinances, and lookback limits vary by jurisdiction and change frequently. The applicable rules follow the location of the role, not your headquarters.

Healthcare and long-term care screening

In post-acute and long-term care the requirement is not abstract. Facilities serve a population that is by definition vulnerable, and screening obligations attach on two separate sides.

On the staffing side, federal participation requirements prohibit employing individuals with certain findings of abuse, neglect, or mistreatment, and require checking the state nurse aide registry. Many states additionally mandate sex offender registry checks for long-term care employees and contractors, and the National Background Check Program established under the Affordable Care Act supported state programs that combine registry and criminal history screening. Registry checks sit alongside — never in place of — criminal history searches and exclusion screening against the OIG's LEIE and SAM.gov.

On the admissions side, several states impose duties when a registered offender is admitted as a resident, ranging from notification of other residents and responsible parties to specific care-planning and documentation requirements. Facilities need this determined at intake, on every referral, before a bed is offered — not discovered afterward.

Build, buy, or both

A reasonable decision rule:

• Employment decisions, any volume: go through a CRA. The FCRA process is the product; the data is the easy part.
• Operational screening in a regulated setting — resident intake, vendor vetting, care planning: an API integration inside a workflow that produces an audit trail and routes hits to a named human reviewer.
• A handful of states, engineering capacity available: direct official sources are defensible and cheap, provided you own the maintenance honestly.
• National coverage on a deadline: a metered sex offender check API covering all 50 states, DC and the territories, with the coverage list and per-jurisdiction freshness written into the contract.

Whichever you choose, the part that determines whether the system works is not the API. It is what happens after a hit: who reviews it, how identity is confirmed, what the subject is told, and whether you can reconstruct the decision a year later. Build that first, and the data source becomes a replaceable dependency.

For the broader picture — criminal history, court records, incarceration data and crime statistics, and how they differ from registry data — see offender and crime APIs.

Key terms