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.
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.
50 states
5 inhabited
territories
Tribes
80%
Official
registries
19%
Public
sources
1%
Mixed
sources
records
have a link to the
public source profile
or registry
page.
Missing source profile link means no stable profile URL is available.
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
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
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
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.
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 |
|
|
HTTP method |
|
|
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 |
|
|
Response speed |
|
|
Uptime |
|
|
Usage tracking |
Requests and approximate cost visible in the dashboard |
|
Billing |
Usage-based, monthly billing |
|
Docs |
|
|
Support |
Email at support@intsurfing.com |
|
Support response time |
|
|
Status page |
|
|
Platform / user cabinet |
How setup works
Register an account.
Add account details. Name and billing address are required for billing.
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.
Accept the Terms of Use and Privacy Policy in the Service tab.
Activate the service.
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
Review technical requirements: volume, expected usage, performance needs, support expectations, and integration details.
Confirm commercial terms: billing model, service expectations, and any custom conditions.
Sign the agreement or SLA documenting the commercial and operational terms.
The API setup is prepared according to the agreed terms.
Start production use.
Operational details
Delivery destination
Client storage or agreed destination
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
Commercial / setup flow
Sign the agreement or SLA before paid delivery starts.
The signed agreement is sent for bank verification. This usually takes 1–3 business days.
After confirmation, Nannostomus sends the invoice.
The buyer completes payment according to the agreed billing period: monthly, quarterly, or annual.
The refreshed dataset is loaded to the agreed destination each month, and the customer is notified by email.
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.
Amazon Web Services
Cloud infrastructure, processing, hosting, and storage.
Apidog
API documentation, testing, and management.
Hutko
Payment processing for card-based API billing.
Microsoft 365
Email, documents, agreements, and invoices.
DocuSign
Electronic signatures for commercial agreements.
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.
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.comSupport intake
The support team reviews the request and identifies the responsible owner.
Technical routing
API access, availability, authentication, and service interruptions go to the technical team.
Data & delivery routing
CSV delivery issues go to the delivery owner. Data quality and refresh questions go to data operations.
Business routing
Agreement, invoice, and commercial questions go to the business contact.
For API availability issues, buyers can also review the status page for active incidents, planned maintenance, and past service interruptions.
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.
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.
The public test key is separated from production access and should be used only for technical evaluation, request testing, and response review.
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.
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
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.