The industry needs some help to drive innovation. Less time spent reinventing the wheel means innovation elsewhere.

Premium paid support will be available to those who need it at the enterprise level.

It's true that the RESO Web API is generally superior to the older RETS standard, and one reason is it typically allows you to efficiently query the API for specific results that could then e.g. be shown on a website. However, here are a number of use cases to sync the data locally.

In the following list, there are ideas that are beyond what this application does on its own. But you'd have the power to take things another step and accomplish things the RESO Web API can't.

• Not all platforms support direct querying via the API. For example, MLS Grid only supports replication.
• Aggregates like "What's the median price?", or "What's the average number of pictures per listing?"
• Massage data
  • E.g. in Phoenix, Ahwatukee is not a city, but people treat it like one. You could make searches done by your users automatically turn requests for the village (not city) of Ahwatukee into a search for the 3 zip codes representing Ahwatukee.
  • Make your own fields. For example, there is no address field, but you could make your own. This could simplify your code.
• Full text search, e.g. searching the public remarks field using full stemming. This would likely require an extra destination not currently offered, such as Elastic Search. But the point is that this can't currently be done via RESO Web API.
• Reference other fields
  • E.g. say I want to do a query to see where ModificationTimestamp != MediaModificationTimestamp on the Media resource. But you can't do such a complex query in RESO Web API.
• Basically anything the RESO Web API doesn't offer. For example, some platforms offer polygon searches. But you can't e.g. search with a simple centroid and radius. If you build your own API using the data synced by this tool, you could do such a thing.

(If you don't fit into any of the cases listed above, then you will probably be better off querying the MLS platform directly.)

Another advantage of syncing the data and creating your own API is you basically avoid quota limits.

Yes, it just syncs the data. But this is the mission of this project and should be a large chunk of any work needed to produce a project that uses the data. You'll still have work left to do such as field mapping (especially if you use multiple MLS sources and intend to harmonize their data and show it in one place consistently). Of course whether you're allowed to show the data publicly is a legal concern you'll need to talk with each MLS about.

Yes! For example there are users running OpenReSync in production with REBNY (New York), UtahRealEstate.com, and RMLS (Portland/Pacific Northwest). Others like Spark haven't been tested yet, but the codebase is set up to add more without too much work.