Trust & Transparency Center

An overview of how Nannostomus provides access to structured U.S. sex offender registry data through API and CSV.

Here, you can see how the dataset is sourced, structured, processed, delivered, refreshed, and supported. You can also find information about our security practices, privacy approach, status handling, and contracting models.

Data foundation

Data sources & coverage

This section explains what jurisdictions are included in the collection scope, what source categories are used, and what source-level limitations buyers should understand before working with the data.

USA coverage map

50 states

5 inhabited
territories

Tribes

80%

Official
registries

19%

Public
sources

1%

Mixed
sources

80%

records
have a link to the
public source profile
or registry page.

Coverage scope

  • Alabama
  • Alaska
  • Arizona
  • Arkansas
  • California
  • Colorado
  • Connecticut
  • Delaware
  • Florida
  • Georgia
  • Hawaii
  • Idaho
  • Illinois
  • Indiana
  • Iowa
  • Kansas
  • Kentucky
  • Louisiana
  • Maine
  • Maryland
  • Massachusetts
  • Michigan
  • Minnesota
  • Mississippi
  • Missouri
  • Montana
  • Nebraska
  • Nevada
  • New Hampshire
  • New Jersey
  • New Mexico
  • New York
  • North Carolina
  • North Dakota
  • Ohio
  • Oklahoma
  • Oregon
  • Pennsylvania
  • Rhode Island
  • South Carolina
  • South Dakota
  • Tennessee
  • Texas
  • Utah
  • Vermont
  • Virginia
  • Washington
  • West Virginia
  • Wisconsin
  • Wyoming

  • American Samoa
  • Guam
  • Northern Mariana Islands
  • Puerto Rico
  • U.S. Virgin Islands

  • Menominee tribal registry source
  • Tribal-related records included in state registries
Source profile links

Missing source profile link means no stable profile URL is available.

Source categories

State, territory, tribal, government, or agency-hosted registry sources.

Used where direct official-source collection is limited, incomplete, unstable, or not technically practical.

Jurisdictions where more than one source type is used to support source continuity or coverage stability.

  • AK Official registry/agency source
  • AL Official registry/agency source
  • AR Official registry/agency source
  • AS Official registry/agency source
  • AZ Supplementary public source
  • CA Official registry/agency source
  • CO Official registry/agency sources
  • CT Official registry/agency source
  • DC Official registry/agency source
  • DE Supplementary public source
  • FL Official registry/agency source
  • GA Official registry/agency source
  • GU Official registry/agency source
  • HI Official registry/agency source
  • IA Official registry/agency source
  • ID Supplementary public source
  • IL Official registry/agency source
  • IN Supplementary public source
  • KS Supplementary public source
  • KY Official registry/agency source
  • LA Supplementary public source
  • MA Official registry/agency source
  • MD Official registry/agency source
  • ME Official registry/agency source
  • MENOMINEE Official registry/agency source
  • MI Official registry/agency source
  • MN Official registry/agency sources
  • MO Official registry/agency source
  • MP Official registry/agency source
  • MS Official registry/agency source
  • MT Official registry/agency source
  • NC Official registry/agency source
  • ND Official registry/agency source
  • NE Official registry/agency source
  • NH Official registry/agency source
  • NJ Supplementary public source
  • NM Official registry/agency source
  • NV Official registry/agency source
  • NY Official registry/agency source
  • OH Official registry/agency source
  • OK Official registry/agency source
  • OR Official registry/agency source
  • PA Supplementary public source
  • PR Official registry/agency source
  • RI Supplementary public source
  • SC Official registry/agency source
  • SD Official registry/agency source
  • TN Official registry/agency source
  • TX Official registry/agency source
  • UT Official registry/agency source
  • VA Official registry/agency source
  • VI Official registry/agency source
  • VT Official registry/agency source
  • WA Official registry/agency source
  • WI Official registry/agency source
  • WV Official registry/agency source
  • WY Supplementary public source

Source-level limitations

The dataset provides structured access to public registry data, but it does not remove all differences created by the original sources. Here is what this can affect.

Field availability

Fields vary by jurisdiction. Some states publish more fields than others.

Record completeness

Record detail depends on what each source publishes.

Status visibility

Status labels vary by source and may not always be available.

Source profile links

Source profile links are available only when the source provides a stable record-level URL.

Update timing

The original source controls when records are added, changed, or removed.

Data refresh cycle

Each refresh starts with a new source load. Buyers can confirm the latest dataset update through the access method they use.

API users

The API response includes a download date field that shows the load date for the returned records.

CSV customers

CSV customers are notified by email when the new monthly dataset has been loaded. Record download field is also available.

Refresh limitations

The original source controls when records are added, changed, or removed. Nannostomus reflects source data through the monthly refresh process, but source changes may happen between monthly snapshots.

Refresh cadence

MONTHLY

by the 15th of every month

Monthly refresh stats

Record and photo count changes compared with the previous month.

View monthly refresh stats

Data structure: 80+ data fields

Personal Details

Aliases

Address Data

Crime & victim

Appearance

Photo

Record link

Full data field list

Close ×

main

Id

Fullname

Firstname

Lastname

Middlename

Title

Sex

NameSuffix

Address

AddressType

City

State

Zip

Zip4

CountyName

AddressDate

WorkAddress

WorkCity

WorkState

WorkZip

WorkZip4

WorkCountyName

BirthDate

Ethnicity

EyeColor

HairColor

Height

Skin

Weight

Email

BirthPlace

Phone

Block

ReleaseDate

Employer

PrevAddress

Address2

Registered

Status

Risk

SourceState

VictimMinor

VictimSex

OffenderLink

SourceId

Age

Hash

alias

OffenderId

Value

Firstname

Lastname

Middlename

Title

Suffix

crimes

OffenderId

CaseNo

Court

ConvictionPlace

ConvictionState

ConvictionDate

OffenseDate

Statute

Description

CrimeLocation

VictimAge

VictimSex

CrimeCity

CrimeState

CrimeCounty

DateReleased

mark

OffenderId

Value

photo

OffenderId

Filename

PhotoUrl

vessel

OffenderId

Make

Type

Color

MotorType

HullMaterial

Year

Tag

Sample data

Response

{
  "Offenders": [
    {
      "FullName": "Oda Rory Blanda",
      "FirstName": "Oda",
      "LastName": "Blanda",
      "MiddleName": "Rory",
      "NameSuffix": "Jr",
      "Title": "Mr",
      "BirthDate": "19790720",
      "Age": "44",
      "Sex": "Male",
      "EyeColor": "Purple",
      "HairColor": "Silver",
      "Height": "6'2\"",
      "Weight": "260 LBS",
      "Ethnicity": "Hispanic",
      "Skin": "White",
      "Phone": "x-69x-293-x198",
      "Email": "Oda.Blanda16@gmail.com",
      "BirthPlace": "2525 Howell Branch Rd, Casselberry, Florida, 32707",
      "Address": "845 Howelsen Pkwy",
      "Address2": "1619 W Baseline Rd, Tempe, Arkansas, 85283",
      "AddressType": "Home",
      "City": "Steamboat Springs",
      "State": "Colorado",
      "Zip": "80487",
      "Zip4": "456",
      "CountyName": "Routt County",
      "Block": "",
      "AddressDate": "20100901",
      "PrevAddress": "5720 Windy Dr, Stevens Point, West Virginia, 54482",
      "Employer": "BLITZ DRILLING",
      "WorkAddress": "41 Wooster St",
      "WorkCity": "York",
      "WorkState": "North Dakota",
      "WorkZip": "10013",
      "WorkZip4": "123",
      "WorkCountyName": "Benson",
      "Registered": "20210525",
      "Status": "Non-Compliant",
      "Risk": "Tier 1",
      "VictimMinor": "False",
      "VictimSex": "Male",
      "ReleaseDate": "20240122",
      "OffenderLink": "https://placeholder.org/offender/123456",
      "SourceState": "CA",
      "SourceId": "40373",
      "Aliases": [
        "Oddy",
        "Sweaty Od",
        "Dulce"
      ],
      "Crimes": [
        {
          "CaseNo": "3AN-01-9AB5",
          "Court": "SUPERIOR COURT JUNEAU",
          "ConvictionPlace": "Pennsburg",
          "ConvictionState": "PA",
          "ConvictionDate": "20230123",
          "OffenseDate": "20220401",
          "Statute": "AS11.41.420(A)(3)",
          "Description": "Attempted Sexual Assault 2",
          "CrimeLocation": "230 Big Trees Rd",
          "VictimAge": "32",
          "VictimSex": "Male",
          "CrimeCity": "Murphys",
          "CrimeState": "CA",
          "CrimeCounty": "Calaveras",
          "DateReleased": "20240120"
        },
        {
          "CaseNo": "01-3AN-2AB5",
          "Court": "Lincoln County Circuit Court",
          "ConvictionPlace": "Cold Brook",
          "ConvictionState": "North Dakota",
          "ConvictionDate": "19870401",
          "OffenseDate": "19860504",
          "Statute": "163.427",
          "Description": "Sexual Abuse First Degree",
          "CrimeLocation": "4570 E Tropicana Ave",
          "VictimAge": "44",
          "VictimSex": "Male",
          "CrimeCity": "Las Vegas",
          "CrimeState": "North Carolina",
          "CrimeCounty": "Clark",
          "DateReleased": "2020316"
        }
      ],
      "Photos": [
        "file-name1.jpg",
        "file-name2.jpg",
        "file-name3.jpg"
      ],
      "Marks": [
        "TATTOO-CHEST",
        "TATTOO-BACK",
        "SCAR-FOREARM",
        "ARTIFICIAL KNEE JOINT"
      ],
      "Vehicles": [
        {
          "Year": "2012",
          "Make": "General Motors Corp.",
          "Model": "SIERRA",
          "Style": "Exo",
          "Color": "GREEN",
          "Plate": "1XX3842",
          "License": "123",
          "State": "WA",
          "Tag": "123",
          "Type": "Track"
        },
        {
          "Year": "2005",
          "Make": "Hyundai",
          "Model": "TITAN",
          "Style": "Modern",
          "Color": "BLUE",
          "Plate": "142XX38",
          "License": "123",
          "State": "HI",
          "Tag": "123",
          "Type": "Van"
        }
      ],
      "Vessels": [
        {
          "Make": "ALUMACRAFT BOAT CO",
          "Type": "AIRBOAT",
          "Color": "YELLOW",
          "MotorType": "IN/OUT",
          "HullMaterial": "Not Available",
          "Year": "2010",
          "Tag": "024264"
        },
        {
          "Make": "PISCES BOAT CO INC",
          "Type": "PONTOON",
          "Color": "RED",
          "MotorType": "OUTBOARD",
          "HullMaterial": "WOOD",
          "Year": "1972",
          "Tag": "12345"
        }
      ]
    }
  ],
  "RecordsFound": 23,
  "RecordsShown": 1,
  "PageNumber": 1,
  "PagesCount": 2
}

Response

{
  "Offenders": [],
  "RecordsFound": 0,
  "RecordsShown": 0,
  "PageNumber": 1,
  "PagesCount": 0
}

Response

{
  "Code": "SexOffenders 1.3",
  "ExitCode": 400
}

Response

{
  "message": "Forbidden"
}

Response

{
  "message": "Too Many Requests"
}

Response

{
  "Code": "SexOffenders 1.3",
  "ExitCode": 500
}

Data quality controls

String sanitization

Escape characters, quotes, backslashes are removed; pipes with periods are replaced.

Uppercasing & trimming

Address, city, county, ethnicity, hair color, skin, status, risk are uppercased and whitespace-trimmed.

Date normalization

Input date formats are parsed and converted to a standard format (yyyyMMdd). Dates outside 1901–today are discarded.

Eye color standardization

Mapped to a fixed set: BLACK, BLUE, BROWN, GREEN, HAZEL, GRAY, MAROON, PINK, RED, MULTI-COLORED, UNKNOWN.

State code validation

Validates and standardizes US state codes using a lookup dictionary (Utils.StateNames).

Sex standardization

Any variant is normalized to Male, Female, or Unknown.

Weight normalization

Non-digits stripped, must be 30–700 lbs, formatted as NNN LBS.

Long string truncation

Crime descriptions and body marks over 7,500 characters are trimmed at punctuation and appended with ....

Age validation

Age must be 10–150; derived from birth date when possible, otherwise discarded.

Address normalization

Fields parsed and cleaned; state/zip extracted from full address strings when missing.

Name parsing

Full names split into first/last/middle/suffix/title components and uppercased.

Photo validation

Photo CSV records with no matching file on disk are removed from the record.

If duplicate records appear inside the same state, one record is retained and duplicate copies are removed.

The deduplication logic uses:

• The generated record hash

• The source state

Cross-state records are not merged. If the same person appears in two different states, the records remain separate.

Before consolidation, the data is split across many small files — chunks.

• Core offender details are stored in main offender records.

• Related data — photos, body marks, vehicles, and other supporting files — is stored separately and linked by record ID.

• Consolidation connects these pieces into the final dataset structure.

Collection checks

We use the proprietary tool for tracking data collection. If any chunk fails during the data loading step, we get the notification that something went wrong and respond to the event. Besides, after each source load, record counts and photo counts are compared with the previous monthly snapshot. We review any unusual changes at the source level.

Missing fields

If a source does not publish a field, the field remains empty in the dataset.

Removed records

Each monthly refresh is built from a new source load. If a registry removes a record and the change is available during collection, the record is removed from the new monthly snapshot.

Wrong data claims

The source registry remains the reference point. Nannostomus does not independently determine offender status.

What these steps help with

More consistent field formatting

Reduced within-state duplication

Cleaner related data

More usable structure

What these controls do not change

Don’t rewrite the facts published by the source.

Don’t remove all source-level differences.

Some fields may be missing because the source did not publish them.

Access models

Technical and commercial details for the available data access models.

Self-service
API access

Instant API access with usage-based billing.

API for higher-volume
or custom requirements

Tailored setup and support for production needs.

CSV

Monthly dataset delivery in CSV format.

Commercial overview

Access model Contracting model Billing Documents
Self-service API
Self-service registration Usage-based, card-based monthly billing Terms of Use, Privacy Policy
Custom API
Agreement-based setup As agreed in the contract Agreement / SLA, Invoices, NDA (on demand)
CSV delivery
Agreement-based delivery Invoice-based Agreement / SLA, Invoices, NDA (on demand)

Technical details

Access method

API key-based access through the platform

Test mode

Public test key with usage and response limitations (available in Docs)

Format

REST / JSON

HTTP method

GET

Search parameters

Name, DOB, city, state, ZIP

Response content

80+ sex offender fields, update date, profile link where available

Batch processing

Not supported

Rate limits

No fixed per-second rate limit for full-access API

Response speed

Around 0.7 seconds

Uptime

99.9%, tracked through the status page

Usage tracking

Requests and approximate cost visible in the dashboard

Billing

Usage-based, monthly billing

Docs

API documentation

Support

Email at support@intsurfing.com

Support response time

1 business day

Status page

Status

Platform / user cabinet

Login

Platform flow

1. Register

2. Add account details

(Name and address)

3. Add payment method

4. Accept terms

5. Activate service

6. Generate key

How setup works

1

Register an account.

2

Add account details. Name and billing address are required for billing.

3

Add a payment method: Visa or Mastercard. You are charged only when usage exceeds the free monthly request quota. The billing cycle begins at the start of the month for the previous month.

4

Accept the Terms of Use and Privacy Policy in the Service tab.

5

Activate the service.

6

Generate an API key.

Operational overview

Intro

For buyers with higher-volume usage or custom production requirements, Nannostomus can review API performance, infrastructure, and support needs before setup.

Who this applies to

Buyers with production traffic, larger request volume, stricter latency expectations, or integration requirements.

What can be discussed

Performance needs, infrastructure allocation, custom limits, support expectations, and response speed.

What stays the same

Same underlying dataset and refresh process.

What may differ

Technical setup, support flow, and commercial terms.

Review process

Discussed with the team before setup.

Commercial setup

1

Review technical requirements: volume, expected usage, performance needs, support expectations, and integration details.

2

Confirm commercial terms: billing model, service expectations, and any custom conditions.

3

Sign the agreement or SLA documenting the commercial and operational terms.

4

The API setup is prepared according to the agreed terms.

5

Start production use.

Operational details

Delivery destination

Client storage or agreed destination

S3 GCS Azure Blob FTP/SFTP direct download, etc.

Scope

Nationwide / selected states

Delivery cadence

Monthly

Update notification

Buyer is notified by email when the new dataset is loaded.

Commercial model

Agreement-based

Billing

Monthly, quarterly, or annually by invoice

Support

Direct communication with support manager and/or technical leadership

Support response time

Priority

Commercial / setup flow

1

Sign the agreement or SLA before paid delivery starts.

2

The signed agreement is sent for bank verification. This usually takes 1–3 business days.

3

After confirmation, Nannostomus sends the invoice.

4

The buyer completes payment according to the agreed billing period: monthly, quarterly, or annual.

5

The refreshed dataset is loaded to the agreed destination each month, and the customer is notified by email.

Technical operations

Operational services, change communication, and support paths for API and CSV access.

External services used to operate the platform, API, billing, agreements, communications, and analytics.

AWS

Amazon Web Services

Cloud infrastructure, processing, hosting, and storage.

API

Apidog

API documentation, testing, and management.

PAY

Hutko

Payment processing for card-based API billing.

M365

Microsoft 365

Email, documents, agreements, and invoices.

SIGN

DocuSign

Electronic signatures for commercial agreements.

GA

GA4 & Search Console

Product and website usage analytics.

Nannostomus tracks operational status, dataset refreshes, and schema-related changes so buyers can understand what changed, when it changed, and whether action is required.

API status

API availability is tracked through the status page. The status page can be used to review current availability, past incidents, planned maintenance, and service interruptions that may affect API access.

Dataset refresh status

Each monthly dataset refresh has update visibility.

  • API users can see the dataset update date in the API response.

  • CSV customers are notified by email when the refreshed dataset has been loaded to the agreed storage destination.

A monthly stats file is also available to review record-count and photo-count changes compared with the previous monthly snapshot.

Schema & format changes

Planned changes are documented before rollout when they may affect integrations, parsing, storage, or downstream workflows.

Field removal

Field rename

Format change

CSV columns

API response

Parsing logic

How changes are communicated

API changes are published in the changelog and communicated directly when they may affect an existing integration. CSV format changes are emailed before the new format is delivered.

Change communication path

Document

Describe the change and affected fields or formats.

Notify

Update changelog and send direct notice where needed.

Apply

Roll out the change on the stated effective date.

Standard support

support@intsurfing.com

Response within 1 business day

1

Support intake

The support team reviews the request and identifies the responsible owner.

2

Technical routing

API access, availability, authentication, and service interruptions go to the technical team.

3

Data & delivery routing

CSV delivery issues go to the delivery owner. Data quality and refresh questions go to data operations.

4

Business routing

Agreement, invoice, and commercial questions go to the business contact.

Higher-volume and enterprise arrangements: support terms may include a named contact, an agreed escalation path, and separate response expectations.

For API availability issues, buyers can also review the status page for active incidents, planned maintenance, and past service interruptions.

Security & privacy

Technical controls for platform access, API access, and CSV delivery.

Account access is required to manage production API keys, service access, usage data, invoices, and support-related information.

Multi-factor authentication is available in the platform. It is optional, but recommended for production users and teams managing API keys, billing, or dataset access.

MFA available

Production API access is controlled through API keys. Keys are generated from the user account and should be treated as credentials.

They should not be exposed in browser-side code, public repositories, shared documents, or public test environments. API requests are made over HTTPS.

If an API key is exposed, contact support so access can be reviewed and the key can be replaced.

API keys

HTTPS

The public test key is separated from production access and should be used only for technical evaluation, request testing, and response review.

Test key

CSV delivery access is configured through the agreed delivery method.

Delivery may use storage-level permissions, private bucket access, SFTP credentials, or another agreed access method.

Access to delivered files is limited by the permissions configured for the delivery destination.

SFTP

Private bucket access

Responsible use

Acceptable use

  • Public-record products

  • People-search or people-lookup products

  • Data aggregation platforms

  • Research and analysis tools

  • Public-data enrichment workflows

  • Internal data review workflows

  • Products where sex offender registry data is one informational signal among broader public-data sources

  • Technical evaluation, testing, product planning, and integration review

Use limitations

  • Not a compliance-grade, screening-ready, or decision-grade product.

  • Should not be used as the sole basis for decisions about employment, housing, credit, insurance, education, eligibility, access, or other formal rights or benefits.

  • Nannostomus does not determine whether a person should be approved, rejected, monitored, restricted, or treated differently.

  • Do not use for harassment, intimidation, public shaming, unlawful discrimination, stalking, or other harmful or illegal activity.

  • Nannostomus does not provide legal advice and does not replace the buyer’s own legal, compliance, or policy review.

Informational data access only.

The dataset is provided “as is” for informational use. Buyers are responsible for their own use, compliance, and end-user disclosures.