MLSimport talks to your MLS over the RESO Web API and hands the result to WordPress. Here is what that means if you are the one writing code.
The short version
MLSimport does not publish a public REST API of its own. The API in question is the MLS’s, and MLSimport is the client. What you get as a developer is a predictable, RESO-anchored data model inside WordPress, overridable templates, and hooks. That turns out to be more useful than another endpoint to authenticate against.
What MLSimport connects to
Nine provider platforms, each with a dedicated connector rather than one generic adapter:
- Trestle
- Bridge
- Spark
- MLSGrid
- Rapattoni
- Paragon
- ConnectMLS
- Realtor.ca
- Bright MLS, handled first-class
Authentication is OAuth 2.0. Bearer tokens are stored and refreshed automatically, so credentials are entered once and not again. Connections can be live-tested from the admin before anything is saved.
The data model
Fields follow the RESO Data Dictionary, so names mean the same thing here as they do in the standard. Over 400 of them are available, and each one you enable is routed somewhere explicit in WordPress.
| RESO field | Typical label | Where it lands |
|---|---|---|
ListPrice |
Price | Post meta |
BedroomsTotal |
Bedrooms | Post meta |
City |
City | Taxonomy term |
PublicRemarks |
Description | Post content |
YearBuilt |
Year built | Post meta |
ListingKey is the identity column. It is what reconciliation matches on, what the activity log records, and what you should key against in your own code rather than the WordPress post ID.
Per-MLS field correlation and aliasing handles the cases where two boards spell the same concept differently.
Photos
Images are remote references to the MLS or its CDN. They are not attachments, and there is no local copy. If your template expects wp_get_attachment_image() to work on a listing gallery, it will not. Use the plugin’s gallery output or read the stored remote URLs.
Front-end building blocks
Standalone mode ships ten page-building blocks. Each one exists as a shortcode, a Gutenberg block and an Elementor widget, and all three produce the same markup:
- Property List
- Search Results
- List Items by ID
- Content Slider
- List per Agent
- Featured Property
- Map with Listings
- Search Form
- Contact Form
- Half Map
Single-property pages are assembled from more than thirty sections covering media, header and identity, body content, location, agent and leads, and interactive tools.
Templates and hooks
- Overridable templates. The standalone front end ships theme-overridable templates, the same pattern WooCommerce uses. Copy the template into your theme and it wins.
- Action and filter hooks. WooCommerce-style hooks run across the standalone system, so you can change behaviour without touching plugin files. The exact hook list tracks the plugin version; ask support for the current one against the build you are running rather than trusting a copy of it on a marketing page.
- No third-party CDN calls. Sliders, maps and the lightbox are self-hosted. Maps are Leaflet and need no API key, with MapBox tiles as an option.
Structured data
Every listing page emits JSON-LD RealEstateListing schema, including geo-coordinates, price and agent. Permalinks are clean, term archives work, and search URLs are shareable and indexable.
Agent and office data
The agent and office enrichment add-on pulls full agent and brokerage profiles from the Bridge Data Output API, attaches them to listings, and deduplicates and caches them. That is what powers multi-listing agent and brokerage pages.
Building something specific and want to know whether a hook exists for it? Ask us, or open a ticket from your dashboard. See also the developers page and the docs.