A public-record API can spare a product team the labour of harvesting data separately from hundreds of government websites. Access to an endpoint, however, does not in itself make the underlying data fit for the workflow being planned.
The technical connection can function perfectly well while the product still leaves basic questions unanswered. Is every jurisdiction the team needs actually covered? Does a single result stand for a person, a property, a filing or an event? What is meant by the update date? Can a record that is returned be traced back to its origin?
Such questions arise across most categories of public data, including court files, property data, business registrations, professional licences, permits, public contracts and registries of individuals. The answers differ from one category to the next, but the method of assessment ought to stay constant.
Begin with the record and the workflow
Ahead of any comparison between providers, establish what the product is meant to do with the data.
A property platform might pull tax assessments using an address or an assessor’s parcel number. A legal tool might track court dockets by case number. A marketplace might verify that a contractor’s professional licence remains active. A civic-data application might examine federal awards from SAM.gov by agency, by recipient or by Unique Entity Identifier.
Every workflow calls for its own search and delivery model. Looking up a single record may sit comfortably within a synchronous API request. Keeping watch over thousands of business filings might call for a change feed. Studying several years of permits or court matters is often better served by a bulk file.
The output expected matters as well. A product that shows a licence status as it stands today carries different requirements from one examining how those statuses have shifted over time.
Set down the queries intended, the volume, the response time and the storage needs before turning to API features. Left undone, a lengthy feature list may obscure a fundamental mismatch between the API and the product.
Express coverage in the terms used by the source system
“Nationwide coverage” reads plainly enough until somebody attempts to measure it.
Property coverage may hinge on counties, since county assessors and recorders hold a great many property records. Coverage of court data may hinge on particular courts, case types and the years to hand. Professional-licence coverage can differ by state board and by profession. Permit data may be arranged by municipality, by department or by permit category.
A coverage statement worth reading should therefore name the relevant units:
- Jurisdictions and agencies covered
- Types of record gathered
- Historical ranges on offer
- Acknowledged gaps
- Variation in fields available
- Sources offline for now
Teams ought to ask, too, whether coverage means current records, historical ones or both. A business-registration API may enumerate active companies in every state yet say little about dissolved entities. A court API may reach civil matters in one jurisdiction and both civil and criminal dockets in another.
A provider that publishes its data collection and processing methodology hands buyers a firmer footing for weighing up such differences.
Establish what a single API record stands for
What counts as a “record” shifts from one dataset to another.
Within a corporate registry, one company may carry formation documents, amendments, annual reports and Uniform Commercial Code filings. In property data, a parcel may carry several owners, deeds and tax assessments. A court case may hold numerous parties, hearings and docket entries. A professional may hold more than a single licence.
A count of records tells you little in the absence of a data model.
Before integrating, work out whether the API hands back:
- One row for each entity
- One row for each event or filing
- A current profile drawn from several records
- A past version of an entity
- A link between several entities
Identifiers merit careful scrutiny. Parcel and docket numbers, licence numbers, permit IDs, business entity IDs: each may hold steady inside a single source system. Across jurisdictions they can clash, unless accompanied by a state, county, court or agency code.
Deduplication raises the same difficulty. Person-level data may call for name and identity resolution. Property data may call for address and parcel matching. Company data may have to separate branches, legal entities and trade names. Ask what the provider merges, what it holds apart, and which identifiers underpin that judgement.
Look past the refresh frequency on the label
A provider may present its data as daily, monthly or real time. That description says nothing about what occurs during an update.
Several collection models exist among public-record APIs. Some put a query to an official source at the moment of the request. Others load full snapshots to a schedule. Others again process incremental updates or change feeds. Each sets up different expectations about freshness, history and momentary source failures.
Dates need defining clearly as well. A response may carry:
- The date on which an event happened
- The date a record was lodged
- The date a status took effect
- The date the source refreshed the page
- The date the provider gathered the record
- The date the provider released its dataset
These dates cannot be swapped for one another.
Teams should also ask how the provider treats corrections, lapsed licences, amended contracts, withdrawn filings and records that vanish from a subsequent collection. Where the product depends on history, establish whether earlier versions are kept or overwritten.
Examine normalisation without losing the source’s meaning
Government systems seldom share a single schema. Dates, addresses, codes for agencies and status labels can diverge even where the records describe comparable events.
Normalisation can render those records easier to query, yet teams need to know what has been altered. Turning state names into two-letter codes is a simple matter. Folding a range of court dispositions or licence statuses into one tidy category demands rather more interpretation.
A sound schema review should take in:
- Field definitions and data types
- Standardised formats
- Absent and partial values
- Fields specific to a source
- Controlled vocabularies
- Durable record identifiers
- Changes of schema version
- Handling of conflicting values
Be wary of normalised labels that conceal distinctions that matter. “Inactive” may mean expired, suspended, voluntarily surrendered or administratively closed, depending on where it came from. Where those differences count for the product, the original value ought to sit alongside the normalised one.
Put the search behaviour to the test
Documentation may set out the parameters available without making plain how they interact.
A name query may run on exact, prefix or fuzzy matching. An address search may look for a formatted street address, a set of geographic coordinates or a parcel. Parameters used together may follow AND logic, OR logic or a weighted relevance score. Results may be ordered by match confidence, by filing date or by some undocumented default.
Try realistic searches before shaping the user experience around them:
- Common names and spelling variants
- Records with fields absent
- Addresses in varying formats
- Case, permit or licence numbers
- Several filters in combination
- Results running across pages
- Queries that match nothing
- Invalid or partial requests
Inspect pagination as well, along with the maximum size of a response, rate limits and batch support. Should the API prove unable to handle the volume planned, the team may need bulk delivery or a scheduled data pipeline in its place.
Insist on provenance with every result
Public-record data is far easier to review when the response holds on to its link with the source it came from.
Provenance fields worth having include the source agency, the jurisdiction, the original record ID, the source URL, the filing or event date and the provider’s collection date. They help teams look into a surprising result, account for differences between sources and pick out records caught up in a faulty update.
The Nannostomus sex offender API, to take one instance, supplies U.S. sex offender registry data in structured form, together with source jurisdiction, download details and public profile links where these exist. The wider point holds for every category of public record: a normalised response should carry enough context to show where the information originated.
A link to the source aids review. It offers no assurance that the agency page behind it is complete, reachable or current at the moment a user opens it.
Scrutinise the operational terms and the limits on use
The last stage of review should address the conditions that surround the data.
Establish how authentication works, what the rate limits are, what response times and service monitoring are promised, which support routes exist and how changes are announced. Work out the total cost at the monthly volume expected, since per-request rates can shift between pricing tiers. Determine whether failed requests are charged for and whether test access runs under the same limits as production.
Then turn to storage, caching, redistribution, attribution and rights over derived data.
Person-level records warrant extra caution. That something is publicly available does not of itself make criminal or registry data appropriate for decisions on employment, housing, credit or other forms of eligibility. The provider’s stated permitted use, the applicable consumer-reporting rules and the product’s own legal review should be in agreement before launch.
Run a representative trial before spending development time
Pick known examples spread across a range of jurisdictions, agencies or record types. Test records both current and historical, inputs that are incomplete, statuses that have changed and the failure cases you expect. Set the returned fields against the original public source and note every limitation the product will have to accommodate.
The point is to find those limitations before they harden into product assumptions.
In closing
A public-record API fit for purpose should make its coverage, its record model, its update process, its schema, its query logic, its provenance and its usage terms intelligible. With those foundations settled, the engineering team can build on the data with considerably fewer surprises.
