RESO Universal Property Identifier (UPI)


The RESO Universal Property Identifier (UPI) is a standard for a single identifier that includes both parcel numbers and the geographies of the authorities that created them. By implementing a UPI within property information records, data providers and consumers can improve data alignment across systems and avoid parcel number collisions.

The business case for the UPI is matching diverse property-related information pieces to the same parcel. A common example is for-sale property listings. A property data aggregator will often receive the same listing from multiple sources but with slightly different addresses on each listing. Some of its property listings across different geographies will have identical parcel numbers, because they come from different parcel-assigning authorities.

The UPI deduplicates these listings across addresses and authorities. It can do so for many business cases, including tax and public records, broker and agent systems, insurance records, environment data, and transactional history records.


The UPI shape was designed to support different geographic methods of identifier creation in one worldwide model. It uses existing national and global standards in its components.

UPI Data Elements

The UPI uses the following data elements in its construction:

Uniform Resource Names (URNs)

The UPI uses Uniform Resource Names for its encoding, which are a type of Uniform Resource Identifier (URI) that allow globally unique identifiers to be created using a namespace. For more information, see RFC 3986.

RESO has a reserved URN which includes v1 UPI identifiers. See section 3.4.2.


The format of the UPI is as follows:


where the items in angle brackets are required and the items in square brackets are optional.

Try the UPI Builder

Example: Basic UPI


Example: UPI with SubParcelNumber

UPIs can also be used to identify subparcel elements of a property, such as parking spaces, outbuildings or air rights. The UPI, with its fixed number of preparcel components separated by colons, can be extended with a :sub: component label followed by the subparcel item identifier.

urn:reso:upi:2.0:US:48201:R000022230:sub:78 - 9.aB

Since the core UPI contains a fixed number of colon-separated components, special characters that exist within components of the UPI are supported. Even colons within a parcel number will be identified as such because of the fixed number of preparcel components for the overall model. In the preceding example, the SubParcelNumber component has special characters.


UPI Usage with Listings and Other Groupings of Parcels

There are common business cases where multiple parcels, or multiple subparcel elements, are grouped together. This could be a for-sale listing with multiple parcels or a for-rent listing with multiple buildings inside a single parcel.

There is demand for standardized ways to represent multiple UPIs for these kinds of business cases, which is an opportunity for future work.

Selecting the Right Parcel IDs

While unique parcel numbers are straightforward to identify in some geographies, they are not in others. Large data aggregators who were early implementers of the UPI have found that the data sets for IDs that they select for parcels do not always match those chosen by other implementers. Without this alignment, the UPI can’t provide its intended benefit.

RESO is conducting research and will document the correct ID data sets to be utilized by implementers as real-world issues are discovered in new geographies.

Developing SubCountry Standards for More Countries

The UPI was created with the understanding that other countries will have different standards than the U.S. for how they identify the parcel-assigning authority. RESO will maintain continual outreach to international organizations to create consensus on how the SubCountry component for each of their geographies will be formed.

In the U.S., GEOIDs are used. In the EU, NUTS is used. Other countries may have their own country subdivisions.

Questions? Please contact RESO.

Retaining Raw Data from Sources

UPI parcel and subparcel components should match the raw data exactly, including capitals, dashes, special characters, spaces, etc.

With version 1.0 of UPI there was an effort to simplify identifiers through stripping some characters, but further research has shown that accuracy is improved when the entire original data set is retained, as in the UPI v2.0 model.

Limits on Rights to Distribute Parcel Data

There are scenarios where the organization wanting to distribute UPIs may be restricted from distributing the actual parcel numbers based on intellectual property licensing issues or local government rules.

The matching and deduplication aspects of the UPI can still add value through a process called one-way hashing. Hashing obscures the actual data from the receiver of the hash. Instead, it provides a cryptographically hashed unique identifier that can be matched across systems, offering data collision-resistance, which is important for the universality of the UPI.

Hashing may remove some of the intended simplicity of the UPI such as human-readability, and could add complexity for data consumers matching properties from data providers that deliver differentiated UPI data, standard vs. hashed.

Example: Hashed UPIs

Given the UPI in the example above,


The hashed UPI, which includes both the version (2.0) and hash function used (sha3-256) is as follows:




If you would like to suggest changes, please open a ticket.

If you have code changes to contribute, fork the repo, clone locally, make the changes, and then make a PR against this repo.

View on GitHub

Run Code Checks   CodeQL