A tenant screening data provider that stays in its lane
Screening platforms are built in layers: the compliant reporting process they run for their customers on top, and the raw public-records layer underneath. Recordpipe supplies the layer underneath, and only that. We are a tenant screening data provider in the infrastructure sense — we collect, normalize, and deliver public court, eviction, and property records to companies that operate their own compliant screening products. We are not a consumer reporting agency, and nothing we ship is a consumer report.
That division of labor is deliberate. Your platform owns permissible-purpose checks, adverse-action workflows, dispute handling, and everything else your obligations require. Our pipeline owns breadth and freshness: more jurisdictions covered, records that arrive as they publish, and a schema your matching engine can trust. Intake requests whose use informs eligibility decisions go through a compliance review before any scoping offer, and we ask you to attest to your own status as part of that intake.
Eviction records data, normalized across jurisdictions
Eviction and civil court data is the hardest public-records category to run at scale, because every jurisdiction publishes differently: field names shift, case types are coded inconsistently, party names arrive in formats that break naive matching, and publication cadence varies from same-week to eventually. A screening platform that ingests this raw inherits every one of those inconsistencies into its match logic.
The pipeline absorbs that variance before delivery. Case types are mapped to one controlled vocabulary. Party names are delivered both as filed and in a normalized form built for matching. Dispositions and statuses are standardized where the source publishes them, and flagged as unpublished where it does not — an honest gap beats a guessed value in screening infrastructure. Every row carries its jurisdiction and a citation to the underlying public filing, so your compliance and QA teams can trace any record back to its source when a question comes in.
Property and ownership data that anchors your matching
Court records alone are a weak matching substrate — names collide, addresses drift, and false positives are the fastest way to destroy trust in a screening product. Property and ownership data gives your matching engine anchors: parcel records, ownership history, and address histories that let you corroborate whether the person in a court record plausibly connects to the applicant in front of your customer.
Recordpipe delivers this as a companion dataset in the same schema discipline as the court feed: consistent identifiers, normalized addresses, and change tracking as ownership records update. Platforms use it to raise match confidence, to distinguish common-name collisions, and to enrich the property side of a rental application with what the county already publishes. How you weight these signals inside your matching logic is your product; our job is that the inputs are current, structured, and traceable.
How screening platforms actually buy: pilot, verify, expand
Nobody should commit to a records infrastructure vendor on a demo. The pattern that works is jurisdictional: pick a pilot set of counties where you can measure quality against data you already trust, run the scoping, and evaluate the sample against your own match benchmarks before signing anything. Scoping costs $500, is credited to the contract, and returns a feasibility read with a sample within 5 business days.
From there, expansion is phased and each phase is fixed-price — you always know what the next tranche of coverage costs before you commit to it. Ongoing delivery runs as change feeds: daily or weekly deltas by webhook or file drop, so your database converges toward the source instead of drifting stale between bulk reloads. Records that disappear at the source drop out on refresh, which matters in a category where staying current is a compliance property, not just a quality one.
What a delivery looks like
| Field | Description |
|---|---|
| case_reference | The case identifier as assigned by the publishing court. |
| case_type | Filing category mapped to one controlled vocabulary across jurisdictions. |
| filing_date | Date the case record published, as issued by the source. |
| party_name_as_filed | Party names exactly as the court record publishes them. |
| party_name_normalized | Cleaned variant built for your matching engine — casing, ordering, and punctuation standardized. |
| disposition_status | Outcome or current status where published; explicitly flagged when the source does not publish one. |
| jurisdiction | Court and county the record was collected from. |
| address_as_filed | Address information as it appears in the public record. |
| parcel_link | Join key into the companion property and ownership dataset, where one exists. |
| change_flag | New, updated, or removed-at-source — drives your delta processing. |