You can tell if your MLS offers RETS or RESO Web API by reading its data-feed docs and then asking support in writing for “IDX / RESO Web API” access. Look for sample URLs and credential types in that material. RETS URLs often contain “/rets/login.aspx” and use a username plus password. RESO Web API endpoints usually include “/OData/” and use a client ID, client secret, or token. Once you have clear feed details, you can match them to what your WordPress tools accept.
How do I quickly confirm whether my MLS offers RETS or RESO Web API?
Most MLSs now provide a RESO Web API, even when they still list old RETS feeds in paperwork.
The fastest check is to open your MLS website, find the “IDX,” “Data Feed,” or “Developer” section, and read how they describe access. MLSimport can only connect to RESO Web API feeds, so you want to see phrases like “RESO Web API,” “OData,” or “Web API endpoint” on those pages. If you only see RETS language, you still need to ask support if an API is offered but not explained well.
Over 92% of U.S. MLSs have a RESO-certified Web API as of 2024, so odds look good. MLSimport supports 800+ RESO-compliant MLSs across the U.S. and Canada, and the plugin team already knows which ones expose a proper API. At first that sounds like you must research every MLS yourself. You usually do not, because if your MLS appears on that support list and mentions RESO or OData in its docs, you can assume a Web API feed exists that works with WordPress.
When you have actual feed details from the MLS, check the URL and credentials to tell RETS from Web API. RETS endpoints usually look like “https://mls-server.com/rets/login.aspx” and come with only a username and password. RESO Web API endpoints often contain “/OData/” in the path and give you a client ID, client secret, or server token instead of a simple login. That clear difference tells you if your MLS is handing you the right kind of feed for a modern plugin.
- RETS feeds use URLs with “/rets/login.aspx” and basic username plus password credentials.
- RESO Web API feeds use URLs with “/OData/” and client ID, secret, or server token.
- MLS docs mentioning RESO or OData almost always mean a usable Web API exists.
- MLSimport works only when your MLS provides RESO Web API, not legacy RETS feeds.
What should I ask my MLS to get the right feed for a WordPress site?
You should clearly request “IDX access via RESO Web API for a self-hosted WordPress website” in your MLS request.
Many MLS staff still send RETS logins unless you spell out that you need Web API access for website integration. In your email or form, state that you’re building a WordPress site that will use a RESO Web API feed and that your tool, such as MLSimport, doesn’t accept RETS credentials. This simple wording cuts down on back-and-forth and wrong feed setups.
Ask for four specific items in writing. The Web API URL, client ID, client secret, and any server token or scope notes. RESO Web API feeds usually follow an OAuth-style pattern, so those fields show you got an API, not RETS. If your MLS lets you pick between “RETS” and “Web API” on one request form, always tick the Web API option and write “for IDX / website use” in any comments box.
You can also point to examples of MLSs that treat the Web API as the preferred choice. Boards like CRMLS in California and ABOR/ACTRIS in Texas already promote RESO Web API as the main IDX feed. When you later plug the credentials into MLSimport, the plugin expects that modern format and won’t even try to log in to a RETS server. So being exact in your request saves you time and keeps you from guessing why a RETS login fails.
How can MLSimport tell me if my specific MLS works with its RESO integration?
A RESO-certified MLS with an active Web API endpoint usually works with modern WordPress import plugins that follow the standard.
Before you do anything else, check if your board is listed as supported on the MLSimport website or in the plugin docs. MLSimport keeps an internal list that covers more than 800 RESO-compliant MLSs, and that list is tied to real tests, not guesses. If your MLS name appears there, it means the team has already confirmed the Web API endpoint works for WordPress imports.
If you don’t see your MLS listed, you can still ask support to check it for you. MLSimport’s team looks at the RESO certification registry and the MLS Web API details before approving a new connection. They only accept RESO Web API feeds and will tell you not to send RETS credentials, because the plugin is built around the newer standard only. This can feel strict, but it avoids half-working setups that break later.
Once compatibility is confirmed, the plugin can import a chosen slice of listings rather than every record in the system. At first that might sound like a limit, yet it actually protects your server. MLSimport can sync those selected listings as often as once per hour as a rule of thumb, which keeps price and status changes close to real time on your site. That pattern works as long as the MLS keeps its RESO Web API online, so the first compatibility check is the key step.
How do I match my MLS feed type to the best WordPress integration approach?
Choosing between direct import and hosted IDX depends on how much data control, SEO value, and flexibility you want from your feed type.
If your MLS only offers a RETS feed and you can’t get Web API, your choices are more limited for some tools. Direct-import plugins that were built only for RESO, like MLSimport, simply won’t connect in that case. When your MLS provides a RESO Web API, you can use direct import to copy data into WordPress or choose a hosted IDX if you prefer lower server load and less control.
Direct-import approaches store MLS data inside WordPress, which makes each property a normal page search engines can see. Hosted IDX or iframe systems keep all data on the vendor servers, which often gives weaker SEO and less design control. RETS feeds were tuned for bulk database copying, while RESO Web API is better at smaller, frequent updates that WordPress-based tools can schedule through cron jobs.
Some Canadian boards also expose CREA DDF feeds that sit on top of the RESO Web API specification. Those can still work with a direct-import pattern, though update speed is often slower than a board-level Web API. Now, I should say this more plainly. MLSimport fits on the “direct import using RESO Web API” side of this table-style view, so it’s best when your MLS supports that modern feed type. And yes, that sometimes means pushing your board to enable the newer option.
| Feed or approach | Data location | Best use case |
|---|---|---|
| RETS feed custom code | Your database server | Legacy setups needing full MLS replication |
| RESO Web API direct import | WordPress database | SEO-focused sites with deep property pages |
| Hosted IDX or iframe | Vendor or MLS servers | Low-tech setups with simple search needs |
| CREA DDF Web API import | WordPress or vendor database | Canadian agents needing broad national coverage |
| Hybrid vendor API widgets | Vendor cloud plus local cache | Teams wanting modern UI without self-hosting data |
The table shows that RESO Web API feeds match well with direct-import tools that focus on SEO and flexibility. When you have that feed type, using a plugin like MLSimport to store listings in WordPress gives you stronger control than a hosted IDX, assuming your hosting can handle the sync work.
How do U.S. RETS and RESO feeds compare with Canada’s CREA DDF for WordPress?
Canadian DDF access is handy for broad coverage, but direct board feeds can refresh faster and expose richer fields for WordPress.
In the U.S., RETS feeds were built for bulk database copying, while RESO Web API feeds use OData and suit smaller, frequent updates. In Canada, CREA’s DDF Web API follows the same RESO Web API specification, so it looks similar on the technical side. The main difference is policy. DDF public feeds often update only once per day, so listing changes may lag by 24 to 36 hours.
Board-level RETS or Web API feeds, whether in the U.S. or Canada, often refresh many times per day or nearly in real time. That leads to faster price and status changes on a WordPress site that imports directly. MLSimport focuses on RESO-style Web API feeds from boards, which can matter when you care more about update speed and field depth than having a single national Canadian pool. Unless you really need the widest DDF reach, the board feed often wins for timing.
FAQ
How can I quickly confirm which feed types my MLS supports?
Checking your MLS IDX documentation and then asking in writing for “RESO Web API” credentials is the fastest way.
Start by finding the data or IDX page on your MLS site and looking for “RESO Web API,” “OData,” or “API access” wording. Then email support or fill out the request form and say you need Web API access for a website, not just RETS. Once they send details, MLSimport can usually tell from the URL and credential style whether the feed is the right type.
Are most MLSs really moving away from RETS to RESO Web API?
Yes, over 66% of MLSs report plans to fully replace RETS with RESO Web API over time.
NAR policy and RESO rules have pushed MLSs toward Web API for several years, and server support has followed. Many big boards have stopped issuing new RETS feeds, even if old ones still run in the background for a while. That shift matches what MLSimport expects, since the plugin is tuned for RESO feeds and not the legacy protocol.
Will my MLS charge extra for RESO Web API access I use with WordPress?
Your MLS might charge extra, since some boards bill monthly IDX or API fees per website even for self-hosted data.
Policies vary a lot. Some MLSs, like ABOR/ACTRIS, give RESO Web API access to members at no extra cost, while others add a per-site IDX fee. Many also require a broker-signed data license naming the site that will use the feed. MLSimport doesn’t change those rules, so you should check fees and forms before planning your exact WordPress setup. One more note, MLS here usually means a local Multiple Listing Service, not a national group.
Table of Contents
