Input and Output Formats
Structure of our API
The structure of our API is streamlined to allow straight forward searching/finding and filtering parcels that fulfill your specific attributes. It uses an open standard format of GeoJSON where applicable.
GeoJSON
GeoJSON is the open standard format for encoding geographic data. For a consistent view of parcel data and ease of interoperability with our endpoints and other tools we strive to accept GeoJSON formatted input and return GeoJSON structured results.
Geometries Supported
We support every favored GeoJSON geometry type in our geojson
request parameter. This includes Polygon, MultiPolygon, Point, MultiPoint, LineString and MultiLineString. Regrid parcels are returned with either a GeoJSON Polygon or MultiPolygon geometry.
Objects Supported
Feature Collections and Features are the larger wrapper objects supported by our API for both input and output.
For all endpoints that accept the geojson
parameter, one can populate this value with a single GeoJSON geometry directly, a Feature containing a geometry (this is the form of a Regrid parcel record) or if there are multiple Geometries to represent, one can POST a FeatureCollection of Features containing any of the various types of GeoJSON geometries.
Many requests will be a single/simple geometry type like a Point, list of points in a MultiPoint or a single Polygon, however there may be cases where one has an assortment of geometry types to query upon. In that case we suggest using a FeatureCollection containing a list of Features of each geometry type. This can allow a request for say, a polygon of a neighborhood or a neighboring parcel or a road (using LineString) to be combined in a single request.
Please note we do not support a GeometryCollection, as although it is part of the GeoJSON spec, many tools do not offer full support and the same results can be achieved using a FeatureCollection containing Features of mixed geometry types.
Input Format
-
As mentioned above all endpoints that support a
geojson
parameter accepts a Feature Collection, Feature, or GeoJSON geometry. -
Parameters that start with
return_
accept a boolean true/false value. This includes parameters likereturn_count
,return_field_labels
,return_stacked
,return_custom
, etc. -
Parameters that start with
return_matched_buildings
,return_matched_addresses
andreturn_enhanced_ownership
are optional parameters that allow one to remove results if these add-ons have been purchased. For example, if you have upgraded your account to return Match Building Footprints, they will be included in results by default unless the parameterreturn_matched_buildings
is set tofalse
.
Output Format
All responses that return parcels are formatted as a list of GeoJSON Features within a Feature Collection, whether it be a list of parcels from the Query by Fields endpoint, or partial parcel records returned in a Typeahead response.
All endpoints return a JSON object containing keys corresponding to the data being returned. This top-level namespacing allows for multiple values to be returned with parcels (or other results).
The 'features' object is an array of parcels in GeoJSON form. The parcel's geometry is contained in the same named key geometry
. There the GeoJSON geometry lives. Regrid parcels usually contain a GeoJSON Polygon. Sometimes a single parcel contains multiple polygons in the form of a GeoJSON MultiPolygon.
The next key properties
in the parcel Feature contains the bulk of Regrid parcel data.
properties object described
headline
: a human-friendly display address for the parcel. If no address is available, it falls back to the parcel number.path
: The parcel's unique identifier as described above in "Parcel Paths Above"fields
: Columns from the parcel table. These include Regrid Schema where available, plus additional columns varying by the particular county & data available.field_labels
: Human-friendly labels for each key infields
.context
: Information about the city or county where this parcel is found, including apath
one can use for further searches on endpoints accepting apath
parameter.addresses
: If add-on is available on your account, an array of additional matched addresses.enhanced_ownership
: If add-on is available on your account, an array of additional ownership records on the parcelscore
: 0-100 available on some responsesll_uuid
: The Regrid Universally Unique Identifier guaranteed to be stable over time and allow direct parcel lookups from a couple endpoints including api/v2/parcels/query and api/v2/parcels/:ll_uuid
Lastly there is an id
field containing an integer ID. This is not an identifier for the parcel record. If you are in need of a stable identifier we recommend using the ll_uuid
field in properties.fields
.
See this truncated response below highlighting the high-level structured described.
Standard Response Format
GET and POST Requests
-
GET requests are accepted for most endpoints. This can sometimes be simpler to craft a request directly in the URL as query parameters. Other times when an input geometry is too large for the URL (over ~2k characters) or the number of parameters becomes unwieldy, making POST requests is a practical choice.
-
When making a POST request any URL parameters are still used by merging in the POST body. This means the POST parameters take precedence over potentially duplicated URL parameters.
Matched Add-Ons
Parcels + Matched Building Footprints
If your account has Regrid Parcel Data + Matched Building Footprints enabled, then by default any Parcel API endpoints that return parcels will also return building data. This can be controlled with the following parameter:
return_matched_buildings
: Set tofalse
to disable building footprint data in the response. Default istrue
when the account supports it.
Response Format
In the standard response format, there is an additional top-level buildings
Feature Collection of Features. Each Feature in the is a building record.
- See the Buildings Schema document for descriptions of the
properties
of each building GeoJSON Feature, or inspect the buildings schema in json form using the API. - Each building has one or more
ll_uuids
listed in its properties. These specify which of the parcels contain or overlap these building footprints and correspond to thell_uuid
field in each of the parcels in theparcels
Feature Collection in the response.
An example response is below, with some coordinates and parcel fields removed for brevity.
Example response
Parcels + Matched Secondary Addresses
Requests
If your account has Matched Secondary Addresses enabled, then by default any of the Parcel API endpoints will include these addresses. You can select this per-call with the following query parameter:
return_matched_addresses
: Set tofalse
to disable matched addresses data in the response. Default istrue
when the account supports it.
Response Format
In the standard response format, the secondary addresses will appear in each parcel feature's properties.addresses
array.
- See the Matched Address Schema document for a list of each field and descriptions, or inspect the address schema in json form using the API.
An example response is below, with some coordinates and parcel fields removed for brevity.
Example response
Parcels + Enhanced Ownership
Requests If your account has Enhanced Ownership enabled, then by default any of the Parcel API endpoints will include this extra ownership data. You can select this per-call with the following query parameter:
enhanced_ownership
: Set tofalse
to disable enhanced ownership data in the response. Default istrue
when the account supports it.
Response Format
In the standard response format, results
is an array of parcel GeoJSON features.
The enhanced ownership will appear in a parcel feature's properties.enhanced_ownership
array.
- See the Enhanced Ownership Schema document for a list of each field and description, or inspect the address schema in json form using the API.
An example response is below, with some coordinates and parcel fields removed for brevity.