ARMLS moved every feed off RETS and onto its Web API. We sync that feed into your WordPress, Laravel or custom site and keep it current every 2 to 3 hours.
Authorization: Bearer {key}GET /$metadataGET /Property@odata.nextLink$filter=ModificationTimestamp gt {last}ARMLS counts its subscribers in the tens of thousands, so a Phoenix broker site is up against a lot of other sites. Plenty of them still carry RETS era code that stopped working when ARMLS switched to the API, and the usual quote is a full rebuild. We have synced this board's feed before, on a multi MLS platform we built and ran from 2018 to 2025. The audit tells you whether your current site can take the API feed instead.
ARMLS, the Arizona Regional Multiple Listing Service, was founded in 1982 and serves brokers, agents and appraisers across the Phoenix Valley. Its own figures, from 2018, put it at over 42,000 subscribers and more than 3,200 offices.
ARMLS licenses its data as four feed types: IDX, VOW, company back office, and a feed of a brokerage's own listings. All of them are delivered over the Web API, which ARMLS runs on the Spark and RESO Web API.
ARMLS gave RETS users a December 2023 deadline to move to the API. A site still built around a RETS download needs its sync moved before anything else on it changes.
The board decides which platform carries its feed. Each route has its own login, paging and limits, and its own page here.
Every new ARMLS feed starts with an intake form. Broker feeds must be tied to an active ARMLS subscriber.
IDX for a public site, VOW for visitors who register, back office for internal tools. IDX feeds are for participating brokers, and agent sites need broker approval.
You or your consultant fill it in. A developer who is not on the ARMLS products page is named on the form as the consultant managing the data for you.
ARMLS Contract Administration handles the agreement. ARMLS reviews the request before anything is issued.
ARMLS issues keys directly. Technical questions go to the ARMLS API team.
The sync runs against the approved feed and is checked against the MLS before your pages switch.
ARMLS documents the feed types and the rules. The technical side follows the Spark and RESO Web API docs.
01IDX, VOW, company back office, and brokerage listings only. ARMLS gives brokers the last one at no cost.
02RESO resources such as Property, Member, Office and Media, with field names from the RESO Data Dictionary. The $metadata document shows what your licence includes.
03A filter on ModificationTimestamp picks up what changed since the last run. Large results page through @odata.nextLink.
04It carries more than IDX but must not be shown publicly. ARMLS treats AVMs as back office tools, though aggregated results may be shown.
05ARMLS notes its API supports live queries. We still keep a local copy, so map search and filters do not call ARMLS on every page view.
06A changes query does not list what left the feed. A daily purge compares listing keys against your copy, and skips the run with an alert if the feed returns too few.
Taken from the board's own published rules and data pages, listed under Sources above. The audit confirms the current version before anything is built.
ARMLS set December 15, 2023 as the deadline to move from RETS to the API, and ends a RETS feed once its transfer is done. Old RETS code has to be replaced, not patched.
ARMLS says feeds are used under broker control. An agent site needs broker approval before it uses a brokerage feed.
ARMLS states that back office data must not be shown publicly or passed outside the brokerage. A public site runs on the IDX feed only.
Every ARMLS feed falls under its Content Access Policy, and IDX products must also follow the ARMLS IDX Rules. Disclaimers and display rules sit in the templates, per board, with the last updated time.
If your site runs an IDX plugin from a vendor on the ARMLS products page, keeping it may be cheaper. If the plugin was built for RETS, the sync moves to a server cron job that fills its own tables, and the theme reads those. The ARMLS key stays in server config.
An ARMLS config entry and a small filter class sit on top of a shared parser. Scheduled jobs run the changes pull, the weekly re-sync and the daily purge. The listing models read local tables, so the ARMLS API is not called on page loads even though it allows live queries.
Any stack that can send a bearer key and run a schedule will do. Fields follow the RESO Data Dictionary, so adding a second Arizona MLS later reuses most of the mapping. Only that board's local fields and disclaimer need new code.
Your listings never go blank. The new sync runs beside whatever feeds the site today, and we only switch when the two match.
We check your ARMLS feed type, your platform and what the site needs to show.
It fills its own tables while your current listings stay up.
Counts, statuses, photos and rosters checked against the feed.
Pages read from the new sync. The old plugin or script is removed.
ARMLS has one delivery route, its Web API, so there is no Trestle or Bridge to weigh. The real choice is between a direct broker feed with a sync built for your site, and an IDX vendor already licensed with ARMLS.
A licensed plugin can be cheaper for a simple site. A direct feed gives you your own data, your own pages and your own search, at the ARMLS broker rates. The audit compares both against what your site has to do.
Your site's address, what it runs on, and which MLS or feed you have access to.
Access, fields, photos, rosters, and how your platform stores listings.
What syncs, how often, what shows where, and a fixed price for the build.
If you go ahead, the $499 comes off the integration.
We are an independent developer. We are not affiliated with, or certified by, any MLS or data provider named on this page.
Send the site's address and the feed you have access to. The audit gives you a written plan and a fixed quote.