AI Search Features

• Utilizing AI-Powered NLP for Real Estate Listing Searches

  Explains how AI-powered NLP converts a natural-language home request into normalized listing filters, preserves multi-turn search context through nlpId, combines visual preferences with image search, supports an OpenAI integration, and handles unsupported or ambiguous prompts so a conversational interface can refine rather than rebuild every query; Related terms include “natural-language property search,” “turn a sentence into filters,” “conversational real-estate search,” “nlpId,” “continue refining the same search,” “visual preference,” “OpenAI integration,” and “unsupported prompt”; Its focus is NLP query interpretation rather than MCP server setup or standalone image search.Popular

• AI Image Search Implementation Guide

  Provides an implementation guide for POST-based AI image search using natural-language descriptions or reference images, conventional listing filters and relevance boosts, and explains how to interpret similarity scores, control result ordering, identify the matching photos, and reorder images so the most visually relevant one is shown first; Related terms include “search listings by photo,” “natural-language image search,” “reference image,” “visual similarity score,” “relevance boost,” “matching photo,” and “AI image ranking”; This is the end-to-end visual-search article, distinct from coverImage selection, photo classification, and image-quality scoring.Some readers

Comparables

• Sold Comparables & Similar (Active) Listings Selection Logic

  Explains how Repliers automatically selects sold comparables and similar active listings, including the property, price, recency and geographic criteria used, ordering and distance information, maximum result counts, and the scarcity conditions that can reduce or eliminate suggestions when a subject property has few genuinely comparable nearby records; Related terms include “automatic sold comparables,” “similar active listings,” “how are comps selected,” “distance and similarity,” “price and recency criteria,” “result limit,” “ordering,” and “why no comparable was returned”; It helps explain Repliers’ built-in selection logic rather than constructing a custom manual comp search.Few readers

• How to Find Comparable Sold or Leased Properties

  Provides a manual comparable-search recipe for a subject property that is not itself in the MLS®, using sold or leased status together with property type, size, bedrooms, location, latitude and longitude, and radius filters, and shows which ranges can be relaxed when an initial query produces too few comparable transactions; Related terms include “find comps for an off-market home,” “subject property is not in MLS®,” “sold or leased comparables,” “bedroom and size range,” “latitude and longitude,” “radius,” and “relax filters when too few results”; Its focus is manually constructing the comparable query from known property attributes.Few readers

• Finding Comparables by Address - Implementation Guide

  Provides a practical two-request comparable-search workflow that first identifies the subject listing by address and extracts its relevant attributes, then searches nearby sold or leased records using property type, size, bedrooms, price, coordinates and radius ranges, with guidance for widening criteria when too few suitable comparables are returned; Related terms include “find comps for this address,” “look up the subject listing first,” “nearby sold comparables,” “leased comparables,” “match bedrooms and size,” “radius,” “price range,” and “widen criteria”; Its focus is the two-call address-based process, especially when the subject is already represented in listing data.Few readers

Filtering

• Searching, Filtering, and Pagination Guide

  Explains the core listings-search request, common price, status, property and location filters, how several criteria are combined, and how page, limit and offset pagination should be used to traverse larger result sets without attempting to load every matching listing in a single response; Related terms include “basic listings search,” “price filter,” “property type,” “status,” “location,” “combine filters,” “page and limit,” “offset,” “next page,” and “too many results”; It serves as the foundational search guide before consulting specialized keyword, map, radius, status, or date articles.Popular

• Using Aggregates To Determine Distinct Values For Filters and Parameters

  Explains how aggregates reveal the distinct values and counts actually present for a field in an authorized MLS® dataset, how listings=false reduces response overhead, how several normalized or dot-notated fields can be requested, and how those results can populate dynamic filters instead of hard-coding values that differ by board; Related terms include “distinct filter values,” “what property types exist on my board,” “count listings by value,” “aggregates,” “listings=false,” “dot-notated field,” “dynamic filter options,” and “do not hard-code MLS® values”; It helps discover the actual data vocabulary available to the current API key.Popular

• How to Search Listings Using Keywords

  Explains the API’s free-text keyword search across configurable listing fields, how to submit multiple desired or excluded terms, when fuzzy matching can help with spelling or phrasing differences, and how keyword conditions interact with ordinary price, property, status and geographic filters to narrow the final inventory; Related terms include “keyword listing search,” “search remarks,” “include several words,” “exclude a word,” “fuzzy match,” “spelling variation,” and “combine keywords with price or location”; Its focus is free-text content matching rather than exact addresses, MLS® numbers, or structured location filters.Some readers

• Searching Listings By Address

  Explains two ways to find listings by address—free-text search across address-related fields and structured street-number, name, suffix, city and postal parameters—while covering active versus unavailable status filters and the normalization limitations that can prevent an exact match when source boards format an address differently; Related terms include “search by street address,” “free-text address,” “street number and street name,” “postal code,” “exact address not found,” “include sold or unavailable listing,” and “MLS® address formatting”; Its focus is locating listing records, while the address-history article focuses on prior transactions after the address is known.Few readers

• How to Search Listings by Agent or Brokerage Using the Repliers API

  Explains how to search listings by agent identifier or name, brokerage office identifier or brokerage name, why stable IDs are preferable to text names, and what ambiguity or cross-board inconsistencies can occur when multiple agents or offices share similar names or an MLS® provides limited member metadata; Related terms include “listings by agent,” “listing agent ID,” “agent name filter,” “brokerage office ID,” “brokerage name,” “same-name agents,” and “member data differs by board”; It is most relevant when identifying inventory associated with a person or office, with stable IDs preferred over ambiguous text.Few readers

• A Guide to Accessing Sold & Leased Listings

  Shows how to retrieve sold and leased inventory by combining current status, lastStatus, sold-date or closed-date ranges, property type and geographic filters, while clarifying the difference between sale and lease results and the parameters needed to include records that are no longer active; Related terms include “sold listings,” “leased listings,” “closed inventory,” “lastStatus,” “sold-date range,” “closed-date range,” “include unavailable records,” and “historical transactions”; Its focus is retrieving completed sale or lease inventory generally, rather than the narrower task of selecting comparables for one subject property.Few readers

• How to Search for Listings with Open Houses

  Shows how to find listings with open houses by setting minimum and maximum open-house dates for a range, using the same date for a single day, or supplying only a minimum date for all future events, and explains how the filter can be combined with location, price and property criteria; Related terms include “open house this weekend,” “open houses on one date,” “future open houses,” “minOpenHouseDate,” “maxOpenHouseDate,” and “combine open house with location or price”; Its focus is listing-level event filtering, not open-house timestamp normalization.Few readers

• Understanding "Plus" in numBedroomsPlus, numBathroomsPlus, numKitchensPlus, and numRoomsPlus

  Explains that numBedroomsPlus, numBathroomsPlus, numKitchensPlus and numRoomsPlus represent additional, commonly below-grade spaces, how those counts should be displayed beside the main above-grade values, how minBedrooms can combine base and plus bedrooms, and how maxBedroomsPlus can be used when a search must still require above-grade rooms; Related terms include “numBedroomsPlus,” “below-grade bedroom,” “additional bathroom,” “main count plus extra count,” “display 3+1 bedrooms,” “minBedrooms includes plus,” and “maxBedroomsPlus”; It is most relevant when a search or UI must interpret the four Plus fields without treating them as ordinary above-grade room counts.Few readers

• How to Search for Freehold Listings

  Explains the practical approximation for freehold inventory using a maximum maintenance-fee value of zero, how to combine that condition with other listing filters, and why the result should be treated as a dataset-dependent proxy rather than a universal legal-tenure field when an MLS® does not expose freehold status consistently; Related terms include “freehold listings,” “no maintenance fee,” “maxMaintenanceFee=0,” “exclude condos by fee,” and “freehold filter”; It is framed only as a practical dataset-dependent approximation, because the condition is not guaranteed to represent legal tenure consistently across every MLS®.Few readers

Locations, Map & Geospatial

• Filtering Listings Geo-Spatially Using the "map" Parameter

  Shows how to filter inventory inside GeoJSON polygon or multipolygon boundaries with the map and mapOperator parameters, combine the geographic shape with ordinary listing criteria, choose inclusion or exclusion behavior, and move complex geometry into a POST request when it is too large or fragile for a GET URL; Related terms include “map parameter,” “GeoJSON polygon,” “multipolygon search,” “listings inside a boundary,” “exclude a polygon,” “mapOperator,” “combine map and price filters,” and “POST complex geometry”; Its focus is spatial inclusion or exclusion with a supplied shape.Some readers

• Map Clustering Implementation Guide

  Provides the server-side map-clustering workflow, including how precision affects cluster size, result and field limits, small-cluster listing details, clusterListingsThreshold behavior, aggregate statistics and heat-map use, and the response fields needed to render, label and expand clusters as a user zooms or pans; Related terms include “map clusters,” “cluster precision,” “cluster size changes with zoom,” “clusterListingsThreshold,” “small cluster listing details,” “aggregate cluster statistics,” “heat map,” and “cluster response fields”; Its focus is server-generated grouping across an area, not overlapping pins at exactly one coordinate.Some readers

• Locations API Implementation Guide

  Provides an implementation reference for the locations and autocomplete endpoints, including MLS-aligned data sources and location types, identifiers and parent relationships, boundaries and radius options, field selection, aggregates and pagination, and patterns for building a typeahead that turns user-selected places into reliable listing filters; Related terms include “Locations API,” “autocomplete endpoint,” “locationId,” “parent location,” “city, area, or neighborhood types,” “boundary,” “radius,” “location aggregates,” “pagination,” and “typeahead”; Its focus is the full geographic data model and endpoint behavior rather than only the combined autocomplete interface.Few readers

• Handling Detailed GeoJSON Polygons in Repliers API Requests

  Explains how detailed GeoJSON polygons can exceed browser or server URL limits and cause a 414 response, and shows how to place the map geometry in a POST JSON body while retaining ordinary search parameters in the query string so complex boundaries can be submitted reliably; Related terms include “414 URI Too Long,” “GeoJSON is too large for GET,” “detailed polygon request fails,” “POST listings search,” “map object in JSON body,” and “keep normal filters in query parameters”; Its focus is transport and request-size problems involving complex geographic shapes.Few readers

• Using Mapping Libraries with Our Real Estate Data APIs

  Explains how to pass Repliers coordinates, clusters, boundaries and other map-ready data into a separately licensed visualization library such as Google Maps, Mapbox or Leaflet, and clarifies the division between Repliers’ listing and geospatial APIs and the third-party SDK responsible for tiles, rendering, controls and interaction; Related terms include “use Google Maps with Repliers,” “Mapbox integration,” “Leaflet markers,” “map tiles,” “render listing coordinates,” “display clusters,” “draw boundaries,” and “third-party map license”; Its focus is integration with a chosen renderer, while the maps-SDK article simply answers whether one is included.Few readers

MLS®-Specific

• PropTx (TRREB) MLS® Filtering Considerations

  Explains TRREB and PropTx-specific filtering issues such as square-footage ranges instead of exact values, listings with missing square footage, price-per-square-foot statistics derived from ranges, age ranges represented through yearBuilt values, and the use of aggregates and range-aware interface labels to avoid false precision; Related terms include “TRREB square footage range,” “missing square footage,” “price per square foot,” “property age range,” “yearBuilt approximation,” “aggregate available values,” and “avoid false precision”; It is most relevant when PropTx source conventions make exact numeric filtering or display misleading.Few readers

• How to Find Listings Using Radius Search

  Shows how to search within a radius measured in kilometres around latitude and longitude coordinates, how to obtain coordinates from an address or map interaction, how to combine the radius with ordinary price and property filters, and how to select a practical distance that balances local relevance with sufficient inventory; Related terms include “listings within X kilometres,” “radius search,” “latitude and longitude,” “geocode an address,” “nearby homes,” “combine radius with price or property type,” and “how large should the radius be”; Its focus is circular proximity searches rather than polygon boundaries.Few readers

• Understanding and Using boardIds in The Repliers API

  Explains how boardId identifies each MLS® dataset enabled on an API key, how to list accessible boards and search all or only one of them, how an explicit board resolves duplicate MLS® numbers, and how to troubleshoot missing results caused by selecting the wrong dataset or assuming a number is globally unique; Related terms include “boardId,” “which MLS® datasets are on my key,” “list boards,” “search one board only,” “search all boards,” “same MLS® number on two boards,” “wrong board returns nothing,” and “disambiguate listing lookup”; Its focus is dataset targeting and board identity.Few readers

• Filtering Listings by Status

  Explains the difference between the legacy status and lastStatus fields and the RESO standardStatus field, maps them to active, pending, sold, leased, expired, delisted and deleted states, and helps developers choose filters that include or exclude unavailable inventory without misclassifying a listing’s current lifecycle stage; Related terms include “active versus unavailable,” “status or lastStatus,” “standardStatus,” “pending,” “sold,” “leased,” “expired,” “delisted,” “deleted,” and “why a listing is missing”; Its focus is status semantics and filter construction rather than the definitions of individual lastStatus abbreviations alone.Few readers

• Passing Multiple Values for the Same Parameter

  Explains the supported ways to submit several values for one filter—repeating the query parameter or using a JSON array in a POST body—how URL encoding applies, and why comma-separated values should not be used because they may be interpreted as one literal value rather than an OR list; Related terms include “multiple values for one filter,” “repeat the same query parameter,” “JSON array in POST,” “OR values,” “URL encode repeated values,” “comma-separated values do not work,” and “one literal string”; Its focus is request syntax rather than general Boolean logic across different fields.Few readers

• Using contains: and notContains: Prefixes in API Filters

  Explains case-insensitive contains: and notContains: filtering within string and array fields, including amenities and descriptive data, how to submit several inclusion or exclusion criteria, how same-field and cross-field logic combine, and when substring matching is more appropriate than exact equality or the case-sensitive not: prefix; Related terms include “contains prefix,” “notContains prefix,” “substring search,” “case-insensitive filter,” “amenity contains,” “exclude text,” “array contains,” and “multiple inclusion or exclusion terms”; Its focus is partial text membership, not exact equality or the case-sensitive not: exclusion.Few readers

• Building an Autocomplete Search Feature with Repliers APIs

  Shows how to build a responsive autocomplete by debouncing user input and concurrently searching listings, structured addresses, MLS® numbers and Repliers locations, then categorizing and merging city, neighborhood, area, address and listing matches into a clear typeahead interface with appropriate selection behavior; Related terms include “typeahead search,” “autocomplete listings and locations,” “debounce input,” “search addresses and MLS® numbers together,” “categorize suggestions,” and “city or neighborhood suggestions”; Its focus is the combined user-interface workflow, while the Locations API guide covers the geographic endpoint itself in greater depth.Few readers

• Bundled Searches Developer Guide

  Shows how bundled searches place several independent listing queries into one POST request, how global filters differ from per-query filters, how the API merges and identifies results, and how the pattern supports map clusters, multiple geographic branches, distinct property categories and OR-style keyword or saved-search experiences; Related terms include “multiple searches in one request,” “bundled POST search,” “global filters,” “per-query filters,” “OR across locations,” “merged results,” “multiple property categories,” and “bundled clusters”; It is most relevant when independent query branches must coexist without the conflicts caused by forcing every condition into one standard search.Few readers

• Understanding Operators In The Repliers API

  Explains Repliers’ Boolean filter logic: repeated values for one parameter are OR alternatives, different parameters are AND conditions by default, and operator=OR broadens the match across different parameter groups, with examples that help diagnose searches returning either no inventory or far more inventory than intended; Related terms include “AND versus OR,” “same parameter repeated,” “different filters combined,” “operator=OR,” “why zero results,” “why too many results,” and “Boolean query logic”; It is most relevant when the relationship between filter groups is the problem, while the multiple-values article focuses on request syntax for one field.Few readers

• Lot Size Filtering with API Parameters

  Explains how to filter by minimum and maximum lot area in square feet, convert acre values before submitting them, combine lot-size constraints with other listing criteria, and diagnose empty or implausible results caused by sending the wrong unit, an inverted range or source data that does not include a usable lot measurement; Related terms include “lot size filter,” “minimum lot area,” “maximum lot area,” “square feet versus acres,” “convert acres,” “empty lot-size results,” “inverted range,” and “missing lot measurement”; It is most relevant when numeric land-area filtering or unit conversion is the central issue.Few readers

• Using minListDate and maxListDate Parameters For Days On Market Filtering

  Explains how minListDate and maxListDate filter by a listing’s original entry date for days-on-market and recent-listing interfaces, how to use either or both ISO dates with additional criteria, and why this differs from update timestamps used for synchronization or change feeds, which include older listings that were merely modified; Related terms include “minListDate,” “maxListDate,” “listed in the last seven days,” “original listing date,” “new listing filter,” “days-on-market search,” and “listingUpdated is different”; It is most relevant when filtering by initial market entry rather than by any later modification timestamp.Few readers

• How to Filter Listings by MLS® Number

  Explains how to look up one or several listings by exact MLS® number, how the API’s default active-only behavior can make a result disappear after a status change, and how to include unavailable inventory so sold, expired, terminated or otherwise inactive records remain retrievable during diagnostics or historical workflows; Related terms include “search by MLS® number,” “lookup several MLS® numbers,” “listing disappeared after it sold,” “exact listing ID,” “include inactive records,” “sold or terminated MLS® number,” and “active-only default”; Its focus is exact identifier lookup, not free-text keyword search.Few readers

• Q&A Related to Filtering

  Answers common filtering-logic questions, including which parameters can be supplied in a POST body, why repeated values for the same field are treated as OR choices, why different filter types are combined with AND by default, and how to structure more complex requests without unintentionally narrowing all results away; Related terms include “can filters go in the POST body,” “same parameter uses OR,” “different parameters use AND,” “why did my combined filters return zero,” and “how to structure complex filter logic”; Its focus is concise answers to common filter-combination questions, with the operators article covering Boolean behavior more systematically.Few readers

• How to Filter Out Properties from Other Countries Using Geographic Boundaries

  Explains how to prevent geographically adjacent but unwanted inventory from another country or region from entering a search by combining the normal property criteria with a GeoJSON boundary for the intended market, creating a precise spatial inclusion filter instead of relying only on inconsistent city, province or country text fields; Related terms include “Canadian listings leaking into a US search,” “properties across the border,” “exclude another country,” “city or province text is unreliable,” “GeoJSON market boundary,” and “spatial inclusion”; It is most relevant when a precise geographic boundary is needed to prevent cross-border or out-of-area results.Few readers

• Searching for Locations Not Found in Our Database

  Explains how to diagnose a city, neighborhood or area name that is not recognized by checking live aggregate values for the authorized MLS® dataset, and how to substitute a custom GeoJSON boundary or coordinate-based search when the desired place is missing, named differently or not represented as a supported location record; Related terms include “location not found,” “unsupported neighborhood,” “city spelling differs in MLS®,” “check aggregate location values,” “custom GeoJSON boundary,” “coordinate search,” and “missing location record”; It is most relevant when the desired place cannot be selected through the normal location database.Few readers

• Using the "not" Prefix in API Filters

  Explains how the not: prefix excludes one or several exact values, nulls or empty fields from normalized and raw MLS® properties, how multiple exclusions combine with the rest of a query, and why its equality and case-sensitivity behavior differs from the substring-oriented notContains: filter; Related terms include “not: prefix,” “exclude exact value,” “exclude several values,” “not null,” “not empty,” “raw field exclusion,” “case-sensitive exclusion,” and “not versus notContains”; It is most relevant when exact inequality is required rather than substring rejection.Few readers

• Handling overlapping Map Pins for units sharing the same address

  Describes interface patterns for listings that share identical coordinates, especially multiple units in one building, including grouping them into a building panel, spiderfying markers, adding a count badge and synchronizing the marker with a result list so users can inspect every unit instead of seeing one pin hide the others; Related terms include “several units share one map pin,” “condo units have identical coordinates,” “overlapping markers,” “spiderfy pins,” “building count badge,” “multi-unit panel,” and “map-to-list synchronization”; Its focus is frontend presentation of coincident coordinates, not server-side clustering across an area.Few readers

• Filtering Listings by Date and Timestamps

  Catalogs the listing date and timestamp filters available in the API, explains what each timestamp represents in a listing’s lifecycle, and shows how to use ranges and sorting for incremental synchronization, webhook recovery, newly listed inventory, recent price changes, listing updates, expiry windows and upcoming open houses; Related terms include “filter by listing date,” “updated since,” “photo update timestamp,” “price change date,” “incremental synchronization,” “webhook recovery,” “expiring listings,” and “upcoming open houses”; It is most relevant when the main uncertainty is which timestamp field or date range corresponds to a lifecycle event.Few readers

• Location Filter Conflicts: Searching Across Areas, Cities and Neighborhoods

  Explains why combining area, city and neighborhood names from unrelated branches of the MLS® location hierarchy can unintentionally require impossible AND matches, and shows how stable locationId values or bundled searches can represent several independent places without losing results to hierarchy conflicts; Related terms include “area and city filters return nothing,” “neighborhood from another hierarchy branch,” “location filters are ANDed,” “multi-city search conflict,” “locationId,” and “bundled search”; It is most relevant when individually valid place names become mutually incompatible in a single hierarchical query.Few readers