The Sex Offender API.

On our index, the most common offense group is sexual offense against a child (46% of registrants whose registry names the offense), then rape or sexual assault (35%) and child sexual abuse material (9%). Every state page shows its own mix; /sex-offense-types explains each category.

Name and aliases, date of birth or birth year, a registry photo where the state publishes one, the registered address, the offense and any tier or risk level the registry assigns, and a link to the official record — plus why the record matched your search.

On five properties, each of which you can test before signing. How many jurisdictions are covered, and whether the vendor will enumerate them. Whether the response reports which sources answered, so an incomplete search is never silently empty. Whether match strength is labelled — an exact date of birth, a birth year, or an age are different grades of evidence and should not be collapsed into one flag. Whether every record carries citable provenance. And whether pricing is predictable at volume. Run the same query against any two vendors and compare the responses side by side.

Every match carries a confidence score, the basis for the match, and per-source provenance with a source citation. Every search can be re-verified live at the source in the same request.

58 registries — the 50 states, DC, and US territories, normalized into one schema and one API call.

The synchronous endpoint answers from our current snapshot rather than dialling out to each registry, and every response reports its own elapsedMs so you can measure it on your own traffic. State-scoped queries return fastest. For bulk and high-volume work, the asynchronous endpoint lets you submit searches and collect the results as they finish.

In practice the terms describe the same thing from two directions. A registry API is named for the source — the 58 official US registries. A database API is named for the shape you receive — one normalized, de-duplicated corpus you query as a single table. Ours is both: we hold the corpus, and every record still points back to the registry that published it, so you can query like a database and cite like a registry.

Yes — that is exactly what it is. The offender search API takes a name, and optionally a date of birth, age or location, and returns scored, de-duplicated records from all 58 US sex offender registries in one call, each citing the registry that published it. One endpoint and one schema, whether you search a single person or batch thousands.

That is the default. An unscoped query fans out across all 58 jurisdictions in one call rather than making you loop state by state, and the response reports which sources answered so a partial result is never returned as an empty one. Scope it with a jurisdictions array when you only want particular states.

Yes. A batch endpoint takes many searches in one request and bills per row, and an asynchronous endpoint lets you submit volume and collect results as they finish. Teams re-screening an existing population generally use batch; teams screening at the point of onboarding call the synchronous endpoint inline.

NSOPW is a public search destination for one person at a time; it is not an API, it returns no structured records, and it cannot be integrated into a product. If you need an answer inside your own flow — scored, cited, in JSON, at volume — that is the gap this fills. See the NSOPW comparison for a feature-by-feature account.

Not on the standard API: standard results are not a consumer report. FCRA-regulated use runs through FCRA Partner Access, a separately enabled service for approved consumer reporting agencies and screening platforms under a written FCRA agreement.