Get started

MLSimport for developers

A RESO-anchored data model, theme-overridable templates, and WooCommerce-style hooks. Build what the client asked for without patching plugin files.

Before you write any code: the feed belongs to your client

The MLS gives data access to your client, the MLS member, in your client’s name. It does not come from you or from us, and the listings have to come through that approved feed, not from copying the MLS website. The approval names the real domain, so ask for Web API access (not RETS) for the live address, not a staging one. See who needs to hold the MLS credentials. For the whole first build, start with how to create an MLS website with WordPress.

New to the terms? Read what IDX means for the sites you build and how a WordPress developer uses the RESO Web API, with the token, the query and PHP code. While approval is pending, build against the Test MLS and the 30-day free trial.

What you are building on

MLSimport writes MLS listings into WordPress as ordinary posts, with fields you chose routed to post meta, taxonomy terms or post content. Names come from the RESO Data Dictionary, so ListPrice means the same thing on every board you ever connect. One site can hold up to seven boards, see connecting more than one MLS. ListingKey is the stable identity, and it is what reconciliation and the activity log match on.

Over 400 fields are available. Per-MLS correlation and aliasing smooths out the boards that disagree with each other.

Templates

The standalone front end ships theme-overridable templates. Copy one into the theme and yours wins, the same pattern you already know from WooCommerce. No child-theme gymnastics, no forking the plugin. The folder name, the files you can copy and the filters on the lookup are in template overrides in standalone mode.

Hooks

Action and filter hooks run across the standalone system. Change output, change queries, change behaviour, all from your own code, including import hooks that change listing data before it is saved. The full list is in the hooks reference. Hooks are added between versions, so check it against the build you are on and ask support if one you need is missing.

Blocks, three ways

Ten page-building blocks (Property List, Search Results, List Items by ID, Content Slider, List per Agent, Featured Property, Map with Listings, Search Form, Contact Form, Half Map), each available as a shortcode, a Gutenberg block and an Elementor widget, all producing the same markup. Single-property pages assemble from more than thirty sections. On a supported real estate theme, the theme’s own property layouts are used instead.

Things that will save you an afternoon

  • Photos are remote. Listing images are references to the MLS or its CDN, not attachments. Attachment functions will not find them.
  • No third-party CDN calls. Sliders, maps and the lightbox are self-hosted. Maps are Leaflet, no API key required, MapBox tiles optional.
  • Structured data is already there. JSON-LD RealEstateListing on every listing page, with geo-coordinates, price and agent. Do not add a second copy.
  • Sync is chunked. Batched, paginated, memory-safe processing, and modification timestamps skip unchanged records. If you hook into the import loop, keep it cheap.
  • Cron is swappable. WP-Cron by default, with a URL trigger if you would rather drive it from a real server cron.
  • There is a search index. Standalone search uses a dedicated index, with a reindex command in the admin tools.

What there is not

There is no public MLSimport REST API. The API is your MLS’s, over RESO Web API with OAuth 2.0, and MLSimport is the client. If you were hoping to query MLSimport from outside WordPress, query WordPress.

Build your own feed code, or use the plugin?

Use the plugin if the listings only need to live on a WordPress site. The few cases for your own code are at the end of this section. The code is the small part: getting listings once takes a weekend, keeping them right for years is the job. A custom build has to do all of this, for every board:

  • Get and renew OAuth 2.0 tokens before they run out.
  • Page through OData queries without missing or doubling listings, and pull only what changed by ModificationTimestamp, with some overlap.
  • Take down homes that sold, expired or left the feed. Boards can fine for listings left up.
  • Handle photos and photo changes for thousands of homes, and back off when the MLS rate-limits you.
  • Log every record so one MLS number can be traced, and map each field to what the theme reads.
  • Show the attribution and disclaimers the board requires, and only the statuses it allows.
  • Repeat it for the next client, because Trestle, Bridge, Spark and the others hand out different login values.

Then boards change rules and fields, and the code needs a developer every time. MLSImport covers that list (see Things that will save you an afternoon), so your hours go to the design, the search pages and the lead forms. Price the upkeep, not just the first connection: what a custom MLS integration costs compared with the plugin. Your own code still makes sense in these cases:

Building for many clients

Keep one setup you can repeat, and keep each client’s MLS permission separate. Each WordPress site needs its own subscription and its own board approval, and one client’s credentials never cover another client’s site. Keep the credentials in the client’s account. Before you hand a site over, check:

  • Board approval and the feed token.
  • The field map and the first import.
  • One known MLS number: its search result, its update and its removal.
  • Page speed, the attribution text and the lead form.
  • Who owns support and billing, and what happens when the client leaves.

Each site’s import history and settings stay in its own WordPress admin. That makes ongoing care a service you can sell: a monthly check of feed health, stale statuses, search speed and forms, priced apart from the build. Admin branding for client users is a WordPress roles question, and it never removes the listing credits the board requires. Agency workflows, white-label and monitoring across sites are covered in MLS websites for teams, agencies and multisite.

When the client asks why the listings belong on their own site

A link to a portal sends their buyer to someone else. On Zillow, the contact button often reaches an agent who paid for that ZIP code. On their own site, the question reaches them. Each home is also a page on their domain that Google can read, which a framed search is not, but do not promise rankings or traffic: other sites carry the same listing text. Their site catches the buyers they already met. The routing table is in Zillow, Redfin, Realtor.com and Trulia vs agent websites, and the framed-search question is answered in do framed property search pages hurt rankings?

Details in the API reference and the docs. Questions a page cannot answer: open a ticket from your dashboard.