No, MLSimport does not publish a formal SLA with a guaranteed uptime percentage or locked refresh window you can quote in contracts. You can instead present hourly automated refresh, stable handling of MLS API issues, and a clear reliability story that combines MLSimport’s sync engine with your host’s SLA. In practice, that gives brokerages near real time data without making legal promises you do not control. At first this seems weaker than a strict SLA. It is not.
Can I present a concrete uptime or refresh guarantee to brokerages?
Hourly sync keeps listing data on the site very close to changes in the MLS system. It is not perfect, but it is close enough for normal use. You can safely describe an “up to hourly” refresh cycle when MLSimport runs on its normal schedule. The plugin checks the RESO (Real Estate Standards Organization) Web API every 60 minutes by default and pulls new or changed listings into WordPress.
That timing is predictable, simple to explain, and easy to drop into an RFP or proposal. Many MLS boards only require IDX data to refresh once or twice per day, so an hourly pull beats those rules by a wide gap. MLSimport runs sync jobs in the background, so agents and visitors just see fresh listings without anyone pressing a button. You can state that price, status, and other key fields are usually updated the same business day, normally within about an hour of the MLS change.
Listing photos are served from the MLS or a content delivery network, not from the agent’s shared hosting account. That setup keeps image uptime tied to the MLS or CDN network, which is built for around the clock use. If an MLS API has a short outage, the site does not go blank. MLSimport keeps serving the last synced data set until the next successful connection, so visitors still see full details instead of errors.
How does MLSimport’s architecture support reliable uptime for a brokerage‑level site?
Storing MLS data locally lets listing pages load even during brief API issues. The core plugin runs inside WordPress, so front end uptime first follows your hosting stack. If a brokerage picks a managed WordPress host that advertises 99.9% uptime, the listing pages powered by MLSimport follow that same public claim. The plugin is just part of the PHP code your server runs, so there is no extra remote frame that can fail on its own.
MLSimport talks to the MLS’s RESO Web API and writes listing data into the site’s MySQL database. Because that data sits locally, each property page and archive view can still load even if the upstream API is offline for five or ten minutes. From a brokerage view, the site behaves like a normal content site during those windows instead of acting like a broken iframe feed. At first you might think a remote widget is safer. It usually is not.
Image URLs stay as references to MLS or CDN endpoints, which shifts heavy bandwidth to the MLS vendor’s systems. That lowers CPU and disk strain on the brokerage’s host, which helps the server stay responsive during traffic spikes. When you describe uptime in a proposal, break it down clearly. The web layer follows the hosting SLA, while MLSimport keeps already stored listing data browsable during short API maintenance windows.
| Layer | What controls uptime | Role of MLSimport |
|---|---|---|
| Website front end | WordPress hosting provider SLA | Runs as a normal plugin |
| Listing database | MySQL availability on hosting | Stores synced MLS fields locally |
| MLS connection | RESO Web API and MLS vendor | Schedules periodic sync calls |
| Image delivery | MLS media servers or CDN | References remote image URLs |
| User experience | Stability of all layers combined | Keeps pages working during short API pauses |
That layered view helps you explain why listing pages usually stay online and quick to load. You can point to the host’s uptime figure, note that data is cached in the database, and show how the plugin lowers stress on the server by offloading images to MLS media systems. It is simple, but it works.
What data refresh behavior can I safely promise in RFPs and proposals?
You can state that listing information refreshes on an automated hourly schedule. That is the main promise you can make. The standard MLSimport setup runs a sync job every 60 minutes, which you can mention directly in proposal language. In that cycle, the plugin asks the RESO Web API for new, changed, or removed listings and writes updates into WordPress.
For a brokerage, the meaning is direct. Status, price, and most other fields are usually no more than one hour behind the MLS itself. That hourly pattern is more active than many MLS rules that only require at least daily refresh. MLSimport lets your site feel closer to a live portal than a slow overnight mirror. For most markets, you can say changes are same day and “typically within the hour,” as long as the API is reachable and cron jobs can run.
When a property goes off market in the MLS, the plugin marks it inactive or removes it from public views at the next sync. That cuts down on stale listings that hang around and upset agents. You can also explain that admins can adjust sync settings in a controlled way. For example, you can shorten checks to 30 minutes for higher end hosting, or relax them slightly if a smaller board wants fewer calls.
How can I combine MLSimport with hosting and MLS policies into a de facto SLA?
You can bundle hosting uptime and hourly sync into a clear reliability story. It is not a signed SLA, but it is practical. The clean way to talk about this is to stack three pieces. Start with the web host’s uptime guarantee, then the MLS’s own IDX timing rules, and then the hourly automation MLSimport handles. A typical managed WordPress host advertises around 99.9% uptime, which you can quote for the website layer.
That host figure becomes the backbone of your proposal language about page availability. On top of that, you can document “up to hourly” MLS data refresh, a simple rule of thumb from the default schedule. Then you add the MLS board’s rule that IDX feeds refresh at least once per 12 or 24 hours as a compliance floor. Written together, those pieces read like a de facto SLA without claiming a legal promise MLSimport has not signed with you.
Many brokerages also care about what happens when something breaks or stalls. So describe failure behavior in plain text, not just the good parts. If the MLS API pauses for maintenance, the site keeps serving the last synced listings until the next successful sync. That story matches how MLSimport works and is strong enough for most IT reviewers who want steady behavior more than legal fine print.
How does MLSimport help reassure brokerages about compliance and operational risk?
Automated syncing and RESO based integration lower both compliance risk and manual work for staff. MLSimport is built for RESO Web API feeds, which many MLS boards now prefer for clear rules and audits. That match means your site pulls data in the same structured way used by larger platforms, instead of scraping or using a legacy feed that might cause policy trouble. Continuous hourly sync also supports common IDX rules for quick removal of off market listings.
This setup centralizes image delivery and data mapping, so you are less likely to see broken photo groups or bad fields after a schema change at the MLS. When data formats or business rules shift, dedicated support can help you adjust mappings or filters without rebuilding the whole site. I will be blunt here. Most teams forget to update old custom feeds, then scramble later. In proposals, you can present the plugin as part of a standards aligned stack that lowers policy risk and cuts the need for staff to babysit listing updates.
- RESO Web API focus keeps access aligned with current MLS compliance standards.
- Ongoing sync reduces slow removal of off market or withdrawn listings.
- Central mapping and CDN images lower risk of broken pages for clients.
- Support helps brokerages react when MLS rules or fields change.
FAQ
Does MLSimport itself publish a formal uptime or data refresh SLA I can quote?
No, MLSimport does not publish a contractual SLA with a set uptime percentage or fixed refresh window for end users. That can feel limiting when you write contracts. But it is honest about what they control.
You can still describe behavior in clear terms, such as “automated hourly sync from the MLS’s RESO Web API” and “local data storage so pages stay available during short API outages.” For hard numbers, lean on your hosting provider’s 99.9% uptime claim and the MLS IDX refresh rules instead of making promises the plugin vendor has not signed.
What happens to my site if the MLS or API vendor schedules downtime?
During an MLS or API maintenance window, the site keeps showing the last successfully synced listings until the next good connection. That means search results and detail pages still open during that time. Users might not see the very latest change, but they see something stable.
Because MLSimport stores listing data in your WordPress database, front end pages do not vanish when the upstream API is offline for a short time. Visitors can still search, browse, and open property details based on cached data. Once the MLS brings the RESO Web API back online, the next scheduled sync run catches missed changes and returns the site to normal near real time behavior.
Can I tune the refresh frequency for a brokerage that wants tighter updates?
Yes, admins can adjust the sync schedule within reasonable limits, as long as hosting and MLS rules allow the change. MLSimport defaults to hourly because it balances freshness, server load, and MLS rate policies. You could say it is the safe middle.
For stronger hosting or very fast markets, your developer or tech staff can shorten the interval, as long as the MLS allows that call volume. For slower boards or budget hosting, you might lengthen it slightly to avoid load issues. The key is to document whatever schedule you choose and describe it in proposals as an operational target, not a strict legal guarantee.
How should I describe reliability in contracts if I cannot quote a strict SLA number?
Most agents talk about reliability in terms of hourly data updates and hosting uptime, not a separate plugin SLA figure. That might feel less formal, but it lines up with how the system really works.
In practice, you can phrase contract language around “hourly automated synchronization with the MLS,” “website uptime following the hosting provider’s 99.9% SLA,” and “continued display of the last synced data during brief MLS maintenance windows.” That wording matches how an MLSimport setup behaves and avoids claims about backend systems you do not directly control.
Table of Contents
