Offendersearch
Criminal API Reference

Verification reports

A timestamped PDF attesting a search was performed, with a neutral citation on every record.

Base URL https://api.offendersearch.app

A defensible artifact for your audit file

A verification report is a branded, timestamped PDF that attests a criminal-records search was performed — the criminal analogue of the Sex Offender API’s report. The document shows the query, the run timestamp and a report id (rpt_…), the matching records grouped by DOB/age match strength (full-DOB match → year match → age match → name-only), each record with its identity and its public source citation (the neutral jurisdiction code plus a last-checked stamp), a records-searched count, and the FCRA “not a consumer report” notice — prominently. A zero-match search renders a clean “no records found” attestation.

The report names states, counties and record kinds — never sources. Every citation is a neutral public code (OK-COURT, TX-DALLAS) with a freshness stamp. No portal, platform or vendor name appears anywhere in the PDF.

POST /v1/criminal/report

X-API-Key, available on every account exactly like /search — no entitlement required, and one-shot inline live mode works the same way. Provide exactly one of two inputs.

Report on a prior search
POST /v1/criminal/report
{
  "searchId": "crs_7f2a1c9e0b4d6a8f1e23",
  "viewerName": "Case Worker",
  "purpose": "Records verification",
  "reference": "FILE-2026-0142"
}
One-shot: run a search inline and render it
POST /v1/criminal/report
{ "query": { "lastName": "Hamilton", "firstName": "Alex", "state": "TX" } }
FieldRequiredNotes
searchIdone of these twoId from a prior /v1/criminal/search on your account. Renders the stored result — it does NOT re-run the search. Bills only the report.
queryone of these twoRuns the search inline (same shape and validation as /search). Bills the call AND the report.
liveoptionalOne-shot mode only — the same live block as /search. Runs the live checks inline (no 202/poll — a report is a synchronous document).
viewerName / viewerEmail / purpose / referenceoptionalPrinted on the document as a record of who ran it and why. Not an access gate.

The response is the PDF bytes

The response is not JSON — it is the PDF (application/pdf), with the report id in the x-report-id header (rpt_ + 12 hex) and the meter events in x-meter-events. The document’s sections, in order: a header identifying that this is a verification of a search performed; the FCRA notice in a bordered box; the search criteria; the search-result summary (records searched, jurisdictions searched, live verifications, matching records); the matching records grouped by match state, each with identity, DOB/age (never a fabricated date), match detail and confidence, and public source citation(s); and the FCRA notice repeated in full at the end.

POST /v1/criminal/report
# Report on a prior search — pipe the PDF to a file, capture the report id.
curl -sS -X POST https://api.offendersearch.app/v1/criminal/report \
  -H "X-API-Key: $OFFENDERSEARCH_KEY" \
  -H "Content-Type: application/json" \
  -d '{"searchId":"crs_7f2a1c9e0b4d6a8f1e23","viewerName":"Case Worker","purpose":"Records verification"}' \
  -D headers.txt -o verification.pdf
grep -i '^x-report-id' headers.txt
# → x-report-id: rpt_dc990869ac3c   (verification.pdf is the application/pdf body)

Billing

criminal_report is a small fixed per-PDF charge ($0.02). A searchId report bills only the report — the search was already billed. An inline-query report bills the search and the report (plus criminal_live_source per completed source if a live block was sent).

The report is a snapshot of one search, not a live query. A searchId report renders the stored result set, so the completeness the search reported is the completeness the document reflects — read counts and sourceStatus on the search before you file the PDF.