Displaying Parcel Boundaries and Public Record Data

Overview

The Repliers Public Record Parcel Data Add-on lets you display property lot boundaries on a map and surface public-record information for the properties inside them. Use it alongside MLS® listings, or let users explore neighboring properties that aren't currently for sale.

Instead of limiting your map to listing markers, you can make individual parcels clickable. When a user selects a parcel, your application can show its boundary, address, and available public-record data, including ownership, assessed value, taxes, lot and building characteristics, and sale history.

Watch the Public Record Parcel Data Add-on walkthrough to see parcel exploration, address search, and listing enrichment in action, or explore the data yourself in our Developer Playgrounds

Before You Begin

You'll need a Repliers API key with access to the Public Record Parcel Data Add-on. Contact our team to confirm access for your account.

The examples below call the Repliers API directly. Include your API key in the request header:

REPLIERS-API-KEY: YOUR_API_KEY

For authentication and key-handling guidance, see our [API Authentication Guide][authentication].

How Parcel Boundaries Work

Public-record parcels are available through the Locations API. Set source=PublicRecord and type=property to request parcel locations instead of cities, neighborhoods, or other location types.

Each parcel location gives you what you need for a map and a property details view:

Important: A parcel record is not an MLS® listing. Finding a parcel does not mean the property is for sale. Continue using listing data for listing status, asking price, photos, and MLS® descriptions.

For the full location model and supported filters, see our Locations API Implementation Guide.

Displaying Parcels on a Map

Step 1: Request Parcels in the Area

Use GET /locations to retrieve parcel locations for the area your user is exploring. This example searches within 1km of the supplied coordinates and requests only the fields needed to draw the boundaries:

GET https://api.repliers.io/locations?source=PublicRecord&type=property&lat=30.2672&long=-97.7431&radius=1&hasBoundary=true&resultsPerPage=100&fields=locationId,name,map.latitude,map.longitude,map.geometryType,map.boundary

hasBoundary=true limits the results to locations with boundary data. The fields selection keeps this initial request focused on the map instead of loading the full public record for every parcel.

For a map viewport or a user-drawn area, pass a search polygon with the map parameter instead. The search polygon defines the area you want to query; the map.boundary values in the response describe the individual parcels.

The Search locations endpoint supports pagination with pageNum and resultsPerPage. The default page size is 100, and you can request up to 300 locations per page. Load additional pages as needed rather than treating the first page as the complete set of parcels for the area.

Step 2: Render the Boundaries

Use each location's map.geometryType and map.boundary together to build the map geometry. Handle both Polygon and MultiPolygon shapes rather than assuming every parcel is a single polygon.

Boundary coordinates are in [longitude, latitude] order. Preserve the coordinate nesting when you pass the geometry to your map renderer.

Keep the locationId attached to each rendered shape so you can retrieve the correct record when a user clicks it. You can then highlight the selected parcel and open its details in a panel or property view.

Our [open-source proof of concept][poc] demonstrates this approach with interactive parcel shapes, listing markers, and a details drawer.

Step 3: Load Details for the Selected Parcel

When a user selects a parcel, retrieve its details using the locationId from the result:

GET https://api.repliers.io/locations?source=PublicRecord&type=property&locationId={locationId}

Replace {locationId} with the ID from the selected result. This request doesn't restrict the response to the lightweight map fields used in Step 1, so the available publicRecord data is included.

This keeps two tasks separate: loading shapes for map browsing, and loading the full record for the property the user actually selects.

Looking Up a Parcel from a Map Click

You can also look up the parcel boundaries that contain a clicked point:

GET https://api.repliers.io/locations?source=PublicRecord&type=property&lat=30.2672&long=-97.7431&pointWithinBoundary=true

Replace the example coordinates with the clicked point. Use pointWithinBoundary=true for containment. A radius search finds nearby locations and is not the same lookup.

Adding Parcel Boundaries to a Listing Page

You don't need to build a separate parcel browser to use this data. The [single-listing endpoint][listing-reference] can include matching public-record locations in the same response as the listing:

GET https://api.repliers.io/listings/{mlsNumber}?boardId={boardId}&locations=true&locationsSource=PublicRecord&locationsType=property

Replace the placeholders with the listing's MLS® number and board ID. boardId is required when your account has access to more than one MLS®.

• locations=true enables the lookup.
• locationsSource=PublicRecord restricts the associated locations to public records.
• locationsType=property restricts them to properties and parcels.

Use the returned locations entries to display a parcel outline next to the listing's photos and description, or add a separate Public Record section to the listing page.

Important: This lookup returns boundaries that contain the listing's coordinates. It's a geographical match, not an address-text match. If a result is unexpected or missing, check the listing's coordinates first.

Tip: Parameter names differ by endpoint. Use source and type on /locations, and locationsSource and locationsType when including locations through /listings/{mlsNumber}.

Finding Parcels by Address

Use Locations autocomplete to help users find properties as they type:

GET https://api.repliers.io/locations/autocomplete?search=123%20Main&source=PublicRecord&type=property&fields=locationId,name,address,map.latitude,map.longitude

The search input must be 3–100 characters. Autocomplete returns up to 10 results per request.

Display the suggestions, keep the selected result's locationId, and use the parcel-details request above to load its boundary and public record. Then move the map to that property and highlight its shape.

If you want the boundary in the autocomplete response itself, add boundary=true and include the required map fields in your fields selection. hasBoundary=true filters for records that have boundaries; it doesn't replace boundary=true when requesting autocomplete geometry.

What Public-Record Information Can You Display?

The boundary is only one part of the property record. Depending on what's returned, your details view can also include:

• Ownership and mailing - Owner names and mailing information
• Assessment and taxes - Assessed value, assessment year, tax amount, and tax year
• Parcel and legal information - Parcel identifiers, legal description, subdivision, and zoning
• Lot and building characteristics - Recorded lot size, building square footage, year built, and other property characteristics
• Sales and transfers - Recorded sale and transfer information

The video shows how these details can sit alongside an MLS® listing or stand on their own when a parcel has no associated listing.

Only display the information returned for the selected record. A boundary is still useful when some public-record fields are unavailable.

Keep Area Measurements Distinct

The proof of concept calculates approximate lot square footage from the parcel geometry. That calculation is separate from recorded values such as publicRecord.lotSizeSqft and publicRecord.totalBuildingSqft.

Label these measurements clearly. A calculated boundary area, a recorded lot size, and a building's square footage are not interchangeable. Also note that the Locations API's top-level size field is measured in square kilometers, not acres or square feet.

Testing in the Developer Playgrounds

You can explore the data before building your interface:

1. Open the Developer Playgrounds and select Locations.
2. Set the source to PublicRecord and the type to property.
3. Move or zoom the map to an area you want to inspect, then review the returned parcels and response data.
4. Select a parcel to inspect its record, or adjust resultsPerPage to see more results in a response.

To test listing enrichment, open a listing in the Listing view, enable locations, and set locationsSource to PublicRecord. Review the returned locations data alongside the listing.

Using the Open-Source Example

Our Public Record Parcel Boundaries proof of concept combines parcel boundaries, active listing markers, sold or unavailable listings, address autocomplete, and property details in a single map interface.

The sample loads lightweight parcel geometry for map browsing and retrieves selected public-record fields when details are opened. It keeps the Repliers API key on the server and uses map position and zoom to control loading.

Use it as a starting point, then adapt the layout and interactions to your application. The sample's marker colors, zoom thresholds, and caching behavior are application choices, not API requirements.

Follow the repository README for installation and configuration. Its /api/parcel-data and /api/parcel-details routes belong to the sample application's server; they are not additional Repliers endpoints.

Troubleshooting

No Parcels Are Returned

• Check that your API key has public-record access
• Confirm source=PublicRecord and type=property are set
• Review the geographical filters; for point lookups, provide both lat and long

Parcel Records Are Returned, but No Boundaries Are Visible

• Check that your fields selection includes map.boundary and map.geometryType
• Not every location has boundary data; use hasBoundary=true when a drawable shape is required
• For autocomplete, also request boundary=true
• When geometry is present, check coordinate order and make sure your renderer handles the returned polygon structure

Public-Record Details Are Missing

• The lightweight map request in this article intentionally leaves out publicRecord
• Retrieve the selected parcel's details before treating those fields as unavailable
• Handle fields that remain absent without substituting unrelated listing values

The Map Shows Fewer Parcels Than Expected

• Check pagination and the area sent in the request
• In the example application, parcel loading also depends on zoom, so zoom in before investigating a missing parcel layer

Responses Are Larger Than Needed

• Keep geometry requests separate from detail requests
• Request only the fields each view uses
• Load additional parcel pages as needed instead of downloading every parcel's complete public record just to draw a map

What questions does this article answer?

• How do I display property lot boundaries on a map, including properties that aren't listed for sale?
• How do I retrieve a parcel's public-record information after a user selects it?
• How do I include parcel boundaries and public records in a listing response?
• How do I build address search that focuses the map on a parcel?
• Where can I test the data and find an example implementation?

Updated on: 18/09/2026