Narrowing Parcel API v1 Search
Narrowing searches by geographic area
Most API requests take an optional
context parameter that will narrow down the search results to a specific geographic area. The
context values are called Place
A state Place
path is most often used and will improve search results. E.g.,
/us/al etc. This is the most commonly used
context in Parcel API requests.
context parameter and Place
path value are most important to provide when doing searches that can have results from many different parts of the US, like address or parcel number searches. The
context parameter should not be provided when doing latitude and longitude based searches.
paths should be lowercase characters and any spaces should be replaced by dashes (-).
path's are administrative boundaries and uniquely reference a geographic region. The Place
path consists of the country, state, county and Census Minor Civil Divisions (MCDs). Minor Civil Divisions are also called "County Subdivisions". For example,
/us/oh/hamilton for Hamilton County, OH.
place paths are two or three levels deep,
/country/state/county. Four level deep
place paths add the MCD and are rarely used for API calls.
PLEASE NOTE: The Regrid Parcel Record attribute
city in our schema is the MCD the parcel is in. To repeat: We use our
city field to hold the name of the Census MCD. Our
scity attribute is the actual city/town/village/etc the parcel is in.
If you are not sure what to use for your API requests, browsing on regrid.com to the desired place and copying the path out of the URL is a good way to get started.
context parameter will return a
400 response code with an
Invalid context path message. If you get this error, you can browse regrid.com to find a valid path for the area you are searching.
Parcel paths are similar to place paths but also include an integer ID at the end. For example,
/us/mi/wayne/detroit/555. These uniquely identify a parcel in our database in a simple, human-readable format. These should be used as described below with the
/parcel.json end-point to quickly and reliably get the full record for a parcel.
To keep from going over your annual or monthly Parcel API Parcel Record limit and receiving overage charges, we encourage users to use the
limit parameter and to check real time usage stats from the Parcel API usage stats endpoint to make sure you have enough remaining before querying for Parcel Records. An email to firstname.lastname@example.org will get things back on track quickly if you run into any issues.
All the fields and data we get from counties are woven into our nationwide standardized parcel schema of over 120 fields. By doing so, our customers are able to work with our data at scale, no matter the geography. Learn more about our standardization process here.
However, every now and then, we get additional fields from some counties that are not included in our standardized schema and are not available to us from all counties. We call them 'Custom columns' and 'non-schema' fields and we pass them along in our data as-is in their raw form as received from the county.
As a result, we provide a boolean flag
return_custom which our customers can use to either remove the non-standardized custom fields to get our standardized schema-only fields or receive the custom columns, based on the preference of your data team and ETL setup.
Parcel API search options
All API requests return a response containing an array of GeoJSON Features of the matched Parcel Records. An empty results set with no error means no Parcel Records could be matched.
You may get multiple Parcel Records per response. This depends on how you search for parcels via our Parcel API. Address matching, parcel number, owner name matching, parcels in a radius or polygon are all examples of Parcel API requests that will likely return multiple Parcel Records in each response.