No. MLSimport does not support RETS at all, and it only works with RESO Web API feeds. The plugin is built for the modern RESO Web API and Data Dictionary standard, which already covers more than 800 MLSs plus CREA DDF® where exposed as RESO Web API. So if your MLS(Multiple Listing Service) moves from RETS to RESO Web API, that is when MLSimport becomes useful, not something you have to replace.
Does MLSImport support both RETS and RESO Web API connections today?
The plugin is built for RESO Web API feeds and skips old RETS connections on purpose.
MLSimport is designed from the ground up to talk only to RESO Web API endpoints that follow the RESO Data Dictionary. That choice means the plugin expects an OData-style URL, a client ID or token, and standard RESO fields, not a RETS login box. In practice, you enter the Web API endpoint your MLS or platform gives you and let the plugin handle the rest.
Because MLSimport is Web API only, its docs are very clear that users must not send RETS credentials for setup. When someone emails RETS URLs with a username and password, support replies that feed type is not accepted and asks for RESO Web API details instead. That keeps the code focused on one standard instead of trying to juggle two very different protocols.
Today the plugin already works with more than 800 RESO-compliant MLSs across the U.S. and Canada, which is roughly 90%+ of all MLS groups. MLSimport also connects to CREA DDF® when the board exposes DDF through a RESO Web API endpoint, so Canadian brokers using the national feed can still use the same workflow. In every case, the plugin expects a Web API connection only.
| Connection type | Supported by MLSimport | Typical credentials format |
|---|---|---|
| Legacy RETS feed | Not supported | RETS URL with username and password |
| Direct RESO Web API from MLS | Supported | OData endpoint plus client ID and secret |
| MLS Grid or similar RESO platform | Supported | Platform OData URL with API token |
| CREA DDF via RESO Web API | Supported | DDF Web API endpoint and access keys |
| CSV or FTP data export | Not supported | Download link and flat files |
The table shows that MLSimport draws a clear line around RESO Web API style connections and does not try to be a RETS client. Once your MLS offers a Web API feed, you can plug it into the same workflow whether the data comes from the MLS, from MLS Grid, or from CREA DDF®.
If my MLS still uses RETS, can I start with that and later switch?
Sites that still depend on RETS feeds should plan a move into Web API support before they adopt this plugin.
MLSimport needs a RESO Web API endpoint and cannot work against a RETS-only server, so there is no simple “start on RETS, flip a switch later” option inside the plugin. If your MLS only gives RETS credentials today, you wait until they set up their Web API before you connect WordPress with this setup. That sounds blunt, but it avoids half-working links that fall apart as standards shift.
Many boards run RETS and RESO Web API side by side for a while, which is when MLSimport fits into the picture. Once your MLS issues Web API credentials, you configure the endpoint in the plugin and begin importing, even if RETS is still active in the background. The team behind MLSimport can help you check when your specific MLS becomes Web API ready so you can time your rollout instead of rushing after a shutdown notice.
How does MLSImport protect my site if the MLS migrates standards later?
Using a Web API first integration cuts most of the pain when an MLS changes systems or retires RETS.
The main shield is that MLSimport only talks to the RESO Web API endpoint the MLS or vendor exposes, not to their internal database or RETS server. When a board quietly turns off RETS, your WordPress site is insulated because its link stays the same OData API URL and the same RESO field names. From your point of view, listings keep syncing and pages keep loading.
The plugin also leans on RESO Data Dictionary fields instead of one-off, vendor specific names. That means your property templates, search filters, and saved queries use stable labels like ListPrice or StandardStatus, not some custom code that breaks every time the MLS vendor renames a column. When an MLS upgrades Web API versions, MLSimport’s connector is what changes, while the posts and taxonomies inside WordPress stay put.
On top of that, incremental sync logic lets you control how hard your site pulls on the API without a redesign. You can run updates every hour, every three hours, or once a day as a simple setting inside the plugin. If your MLS tweaks rate limits or refresh rules after a migration, you just adjust the schedule rather than rebuild your integration.
- The plugin hides backend MLS changes by always talking through a stable RESO Web API layer.
- Templates in WordPress use RESO Data Dictionary fields, not vendor specific column names.
- Connector updates handle new API versions while imported posts remain unchanged.
- Incremental sync scheduling can be tuned as MLS policies or rate limits change.
Will MLSImport keep working if my board joins MLS Grid, Trestle, or another platform?
When an MLS switches distribution platforms, you usually update API credentials, not rebuild your entire website.
Many of the 800+ boards supported by MLSimport already sit behind platforms such as MLS Grid, CoreLogic Trestle, Bridge Interactive, or similar OData gateways. From the plugin’s point of view, these are all RESO Web API endpoints that provide Property, Media, and related resources in a standard way. You configure the platform’s URL and token once and let the importer handle field mapping and sync.
If your board later moves from one platform to another, the most common change is a new endpoint URL and a fresh set of credentials. MLSimport’s settings page is built so you can swap in that new URL and key without touching your theme, search widgets, or existing listing posts. The imported data in WordPress keeps its IDs and URLs, which helps preserve SEO for address pages and community pages.
Now, when this kind of vendor migration happens, people sometimes panic and expect a full rebuild. Most of the time that is not needed, which can be surprising the first time you go through it.
When this vendor change happens, support for the plugin can step in to check the new endpoint and confirm that the data dictionary mapping still lines up. In many real sites this turns into a 30 minute adjustment, not a multi week rebuild. That is the sort of change the Web API only design of MLSimport was meant to handle, even if it never feels fun while you are mid migration.
How do I verify my MLS is compatible with MLSImport’s RESO Web API approach?
Checking that your board exposes a RESO Web API endpoint gives you a clear yes or no for fit.
The fastest step is to look up your MLS in the public supported boards list that MLSimport maintains, which already includes more than 800 RESO certified groups in the U.S. and Canada. If your board appears there, the team has already checked that a working Web API endpoint exists and that the data dictionary meets what the plugin expects. That alone tells you the technical side is ready.
You can also look at the raw credentials your board sends. A compatible feed will list an OData or “/OData/Property” style URL plus a client ID, secret, or server token, not just a RETS URL with username and password fields. If you only see the word “RETS” and no sign of Web API in your paperwork, you know the board has not given you what MLSimport needs yet. In that case, you request RESO Web API access from the MLS or platform.
For extra certainty, some site owners cross check the MLS name inside the RESO public certification registry to see that Web API compliance is listed. If there is any doubt, you can send the documentation or sample credentials to MLSimport support before starting a full import. They can pre check the endpoint, which may save you hours of trial and error later, or maybe not, depending on how clean the MLS setup is.
FAQ
Does MLSImport work with RETS feeds at all?
MLSimport is designed around RESO Web API and does not currently consume raw RETS feeds.
The plugin expects an OData style Web API endpoint and RESO Data Dictionary fields from your MLS or platform. If your board only offers RETS right now, you wait until they roll out Web API before using this setup. That approach keeps configuration simple and keeps you aligned with the industry long term standards.
What happens on my site when the MLS turns off RETS and goes Web API-only?
When an MLS retires RETS in favor of Web API, MLSimport users usually do not change any site templates.
Your WordPress theme works against local posts and RESO field names that the plugin already mapped, not against the MLS transport protocol. As the board cuts RETS and shifts vendors behind the scenes, your job is mainly to keep the Web API credentials in MLSimport up to date. Listing pages, URLs, and SEO work stay the same across that change.
Can Canadian agents use MLSImport with CREA DDF?
Canadian users can use MLSimport when CREA DDF or their board exposes a RESO-compliant Web API endpoint.
Where DDF® offers Web API access that follows the RESO OData pattern, the plugin connects much like it does to a U.S. MLS. You provide the DDF Web API URL and keys, choose what to import, and let it sync into WordPress. The main limits you see come from DDF policies themselves, such as update frequency or which fields CREA includes.
Can I move from another IDX or RETS-based plugin to MLSImport?
Switching from an IDX(Internet Data Exchange) or RETS-based plugin to MLSimport is a one time mapping step followed by a fresh import.
In real projects the move usually looks like this: you disable the old RETS or iframe plugin, configure Web API access for your MLS, map key fields inside MLSimport, and run a new import to create clean property posts. Expect a short overlap where both plugins are present while you test, but long term your site runs only on the Web API native integration.
Table of Contents
