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 paths.
A state Place path is most often used and will improve search results. E.g., /us/mi, /us/al etc. This is the most commonly used context in Parcel API requests.
The 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.
All paths should be lowercase characters and any spaces should be replaced by dashes (-).
Place paths
Place 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.
Most place paths are two or three levels deep, /country/state or /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 app.regrid.com to the desired place and copying the path out of the URL is a good way to get started.
An invalid 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
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 look up a single parcel record, you can search by parcel path or ll_uuid.
Best Practices
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 tech@regrid.com will get things back on track quickly if you run into any issues.
Schema-Only Fields
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.