Submit US street addresses and get each one back as a row - the address as you sent it, latitude and longitude, a normalised match, a residents column, and a status saying what happened. This is a people-search source, so the rules are on this page rather than buried in a policy, and so is the fact that every run we hold came back blocked.
This section sits before everything else on purpose. FastBackgroundCheck is a background-check and people-search site, and a service that resolves who lives at an address carries obligations most scraping does not. These restrictions are not house rules we invented - they are law where most of our customers operate.
Do not use this to decide employment, credit, insurance, housing or a tenant application. In the US those are regulated purposes that require a consumer reporting agency operating under the FCRA, and this is not one - the word “background check” in the source's name does not change that. No configuration of this service makes it one.
Do not use it to trace, doorstep, monitor or contact someone who has not asked to hear from you. Turning an address into a name is exactly the step that makes this category sensitive, and accounts doing it get closed.
Resolving a messy address column to a normalised address with coordinates is an ordinary data-quality task. It is also, in the runs we hold, the only part that returned anything - so if that is what you need, size your expectations accordingly.
When an address on an account you already hold looks inconsistent with what is publicly listed, checking it is a defensive use rather than an investigative one. That is a different activity from building a household directory, and only the first is in scope.
Putting this after a feature grid would be dishonest. Here is exactly what our own runs returned, and what that does and does not tell you.
We hold six real exports of this service, dated between 2026-07-10 and 2026-07-15. Every one is a single row for a single address - 321 California Ave, Palo Alto, CA 94306 - and all six are identical. The columns that carried a value were address, lat, lon and matched_address. residents was empty in all six, and status read exactly the same thing every time: “blocked (needs residential proxy)”.
That is a statement about how the requests were routed, not about the address. A block is not the same as an empty result: it means the lookup did not complete, so it is not evidence that nobody is listed there. It is also not evidence that the service never returns residents - six identical runs against one address establish neither. What we can say is that we have never observed the residents column carrying data, and we would rather write that down than imply otherwise.
So the data dictionary below publishes six column names taken byte-for-byte from the export header, and is explicit about which four we have seen fill. If residents is the column you are buying, test it on the free tier first - that costs nothing and answers the question for your addresses rather than ours. Its sibling Whitepages Addresses Scraper asks the same question of a different source and reports its own results just as plainly.
A street address is the entire input. There are no filters to configure.
status column first.Write addresses the way you would type them into a search box - 321 California Ave, Palo Alto, CA 94306. Start with a small batch: status will tell you what you are actually getting back before you spend on a large one.
Every name below is copied byte-for-byte from the header row of our exports. Unusually for this catalogue, the JSON and the spreadsheet agree exactly - same six columns, same order, in all six runs.
status explaining why.blocked (needs residential proxy).Four of six columns confirmed, one never seen filled, and a status column that told us why. That is the whole measurement, and it rests on one address across six runs - far too little to express as a fill rate, so this table does not try. What it does establish is the schema: six columns, stable across every run and identical between the JSON and the spreadsheet. Spend a few free-tier rows on addresses whose answers you already know before you build anything around residents.
Each of these came out of reading the exports rather than a reference - there isn't one for this service, which is itself the fourth note.
It is the column that tells you whether the row means what you think it means. A residents cell can be empty because nobody is listed, or because the lookup never completed - and those are opposite conclusions. In our exports the value was always blocked (needs residential proxy), which is the second case. Branch on status, never on emptiness.
There is only one export shape here - six columns - and unlike several services in this catalogue, the JSON and the spreadsheet emit them in the same order, in all six runs. That makes the importer simple. Read by name anyway; it costs nothing and survives the day a seventh column appears.
A blocked lookup still produces exactly one row, with the address resolved and residents blank. Your output row count therefore keeps matching your input row count, which makes billing exact and reconciliation trivial - but it also means row count tells you nothing about success. Count status values instead.
Sibling services quote a per-request batch size because their references publish one. This service has no endpoint documentation we can point at, so we do not quote a number - and you should treat any number you see elsewhere with the same suspicion. Start small, watch status, and scale from what you observe.
The uses below are the ones this service is for. The ones it is not for are at the top of the page, and they are not negotiable.
Addresses typed by humans arrive abbreviated, misspelled and inconsistently ordered. Submitting them here returns matched_address - one full postal form with street, neighbourhood, city, county, state, postcode and country - plus lat and lon. In our own runs this is the part that worked on every row.
Address records disagree, and the disagreement is often the finding. Running the same list through this and the Whitepages Addresses Scraper gives you two independent answers and two status columns - which is how you find out whether a gap is the address or the source.
When the address on an existing account looks inconsistent with what is publicly listed, resolving it tells you whether the discrepancy is a typo or something else. This is a defensive check on your own data - not a way to find out who lives somewhere, which is covered by the permitted uses above.
No subscription, no minimum, no per-seat licence. Your first 500 rows are on us - after that, pay-as-you-go.
Every new account, one-time. No credit card required. Given that every run we hold came back blocked, these free rows are not a nice-to-have here - they are how you find out what this returns for your addresses before you spend anything.
Roughly $2 per 1,000 addresses, one row per address - exact to budget, because a blocked lookup still returns exactly one row and is billed like any other.
Volume pricing, SLAs, dedicated workers and bespoke onboarding for teams re-checking a large address file on a schedule. Tell us your numbers and we'll quote.
LIVESCRAPER10 at checkout.Both of these sit in the same restricted category as this page, and the same permitted uses apply to them.
The same question put to a second source, with a documented endpoint behind it and thirty-three declared columns instead of six. Its page reports its own results just as plainly as this one does.
The phone-number half of the same public-records family, with its own measured hit rate and the same restrictions. Use it when the identifier you hold is a number rather than an address.
Most pages in this catalogue describe facts about businesses or software. This one does not, and the difference is worth stating plainly rather than glossing.
FastBackgroundCheck is a US people-search site: it compiles public records and lets visitors look up a person by name, phone number or address, describing its address search as showing the people or business currently at an address along with previous residents. That is the material this service reads - but the subject of those records is a person, and that changes your obligations rather than ours. Under GDPR a household name and address is personal data whether or not it was easy to find, and in the US, using it for employment, credit, insurance or housing decisions is a regulated purpose this service is not licensed for.
The name of the source matters here. “Background check” describes what the site is for, not what you are permitted to do with data taken from it: a genuine background check for an eligibility decision has to come from a consumer reporting agency operating under the FCRA. This is not one, and neither is the site. If the job you have in mind is a screening decision, this is the wrong tool and no configuration of it will make that right.
On our side: publicly available sources only, no third-party trackers on the data layer, and your exports auto-delete after 30 days. We do not keep a copy of your results, and we do not build a database out of them.
The questions we hear most. Anything else? Talk to us - humans, not bots, write the answers.
residents column was empty every time, and status read blocked (needs residential proxy) in all six - meaning the lookup did not complete, rather than that nobody was listed. That is a different thing from a confirmed empty result, and we are not going to present either one as a success. Test it on the free tier with addresses you already know before you plan around that column.address as you submitted it, lat and lon, matched_address normalised to a full postal form, residents, and status. In our runs the first four carried a value on every row, residents never did, and status explained why. The schema is stable - same six columns, same order, in every run and in both the JSON and the spreadsheet.status carried in all six of our exports. Treat it as “no answer yet” rather than “no residents”, and do not let a blocked row silently become a negative result in whatever you build downstream.status column, and scale from what you actually observe.Paste a small batch and read the status column. Your first 500 rows are free and need no card - which, on a service where every run we hold came back blocked, is exactly how you should evaluate this one.
FastBackgroundCheck is a US people-search and public-records site. It lets a visitor search by name, phone number or address, and it describes its address search as returning the people or business currently at an address together with previous owners and residents. This service reads that address search at scale: submit a list of US street addresses and each one comes back as a single row, so an input file and an output file line up exactly, including for addresses where nothing is found.
Each row carries six columns, and those names are measured rather than assumed - they are copied byte-for-byte from the header of six real exports. They are the address exactly as submitted, latitude and longitude as strings, a matched address normalised to a full postal form running from street through neighbourhood, city, county and state to postcode and country, a residents column, and a status column. The schema is unusually stable for this catalogue: one export shape, the same six columns in the same order in every run, and no disagreement between the JSON and the spreadsheet versions of the same file.
What those runs returned is the part worth reading before you sign up. All six exports are single-address tests of the same address, all six are identical, and in every one the residents column was empty while status read exactly “blocked (needs residential proxy)”. That is a statement about how the request was routed rather than about the address itself, which makes it different from a confirmed empty result: a block means the lookup did not complete, so it is not evidence that nobody is listed, and six identical runs against one address are not evidence that the column never fills either. What can honestly be said is that we have never observed the residents column carrying data, and that is what this page says. Two consequences follow for anyone writing an importer. Read status before anything else, because an empty residents cell has two opposite meanings and only status distinguishes them. And do not assume a per-request batch limit: unlike its sibling service this one has no published endpoint reference, so no documented number exists and this page deliberately quotes none.
The obligations that come with people-search data are set out at the top of this page rather than buried in a policy. It must not be used for employment, credit, insurance, housing or tenant decisions - those are regulated purposes in the US requiring a consumer reporting agency under the FCRA, and the word “background check” in the source's name does not change what you are permitted to do with the output. It must not be used to locate, approach or monitor a private individual. Cleaning an address column you already hold, comparing two sources against the same list, and verifying an address against your own records are the uses it is for, and address resolution is the part that worked on every row we ran. Publicly available sources only, no third-party trackers on the data layer, and exports auto-delete after 30 days. Your first 500 rows are free and need no credit card - on this service in particular, spend them before you spend anything else.