> ## Knowledge Base Index
> Fetch the complete knowledge base index at: https://help.repliers.com/sitemap.xml
> Use this file to discover available pages before exploring further.
> Pure-Markdown content can be obtained by appending a '.md' suffix to the content URLs listed in the sitemap (without the trailing slash).

# 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](https://www.youtube.com/watch?v=IBn0vUXaDek) to see parcel exploration, address search, and listing enrichment in action, or explore the data yourself in our [Developer Playgrounds](https://playgrounds.repliers.com/)

## 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:

| Field | How to use it |
| ---- |
| `locationId` | Identify the selected record and retrieve its details. |
| `name` and `address` | Label the parcel and display its address. |
| `map.latitude` and `map.longitude` | Position the map around the property. |
| `map.geometryType` and `map.boundary` | Render the parcel's shape. |
| `publicRecord` | Display the property's available public-record information. |

**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](https://help.repliers.com/en/article/locations-api-implementation-guide-s4c68b/).

## 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](https://docs.repliers.io/reference/get_locations-autocomplete) 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](https://help.repliers.com/en/article/locations-api-implementation-guide-s4c68b/) 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](https://playgrounds.repliers.com/) 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](https://github.com/Repliers-io/Public-Record-Parcel-Boundaries-POC) 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?