March 2026 Update: The unitNumber and unitType fields are now supported as separate inputs for the Property Lookup API. See below for details.
March 2026 Update: unitNumber and unitType Now Supported as Separate Fields
The Property Lookup API now accepts unitNumber and unitType as dedicated address fields. When provided, these values are appended to the street address before matching — no need to manually format the street string.
Most common pattern — single unit column:
If your data source has a single unit column containing values like APT 207 or UNIT 1, pass the entire value in unitNumber:
{
"street": "123 Main St",
"unitNumber": "APT 207",
"city": "Phoenix",
"state": "AZ",
"zip": "85001"
}
Separate unit type and unit number columns:
If your data source has distinct unit type and unit number columns, you can provide both fields:
{
"street": "123 Main St",
"unitType": "APT",
"unitNumber": "207",
"city": "Phoenix",
"state": "AZ",
"zip": "85001"
}
unitType accepts the following values: APT, UNIT, STE, FL, BLDG. Note that unitType has no effect unless unitNumber is also provided.
Both patterns are supported. If you currently embed unit information directly in the street field, your existing integration will continue to work as-is:
{
"street": "123 Main St APT 207",
"city": "Phoenix",
"state": "AZ",
"zip": "85001"
}
No changes are required for existing integrations.
Supported Address Fields
The Property Lookup API accepts the following address input fields:
street— Street address. Unit information can be included here or provided viaunitNumberandunitTypecitystatezipzipPlus4unitNumber— Unit or apartment number (e.g., "APT 207", "4B"). When provided, appended to the street before address matchingunitType— Unit type prefix (e.g., APT, UNIT, STE, FL, BLDG). Optional — only takes effect when used together withunitNumbercounty
Property Search Not Affected
The Property Search endpoint continues to support unitType as a filter option and is unaffected by these changes.
