Spark serves MLS data over the RESO Web API, the same standard as Trestle, Bridge and MLS Grid. We sync it into your WordPress, Laravel or custom site and keep it current every 2 to 3 hours.
Authorization: Bearer {token}GET /$metadata$filter=ModificationTimestamp gt {last} and le {now}@odata.nextLinkListPrice to priceSpark was not one of the feeds on the multi MLS platform we built and ran from 2018 to 2025. It speaks the same RESO Web API, so it uses the same sync engine, paging, purge and parsers. The audit checks your Spark access first, before you commit to anything.
Spark is the developer platform run by FBS, the company behind the Flexmls MLS system. It lets developers request data from participating MLSs once the MLS and its members authorize the application. Access is sold as data plans through the Spark Datamart.
There are two ways in: the Spark API, FBS's own interface, and a RESO Web API endpoint that uses the same keys. The RESO endpoint maps Flexmls fields to the RESO Data Dictionary where it can. The Spark API adds data that RETS never carried, such as saved searches, contacts and market statistics.
Spark was not one of the feeds on the platform we ran. Everything on this page about Spark is taken from its public documentation.
Spark sells access through its Datamart, but each MLS decides who gets a key.
Registration is free. Spark says activation takes up to 3 business days and comes with demo credentials, which only show sample data.
Most integrations need a bearer token key, with a token that does not expire, tied to one Flexmls user. OpenID Connect keys are for apps where agents sign in with their own Flexmls login.
In the Datamart, find your MLS and its plans: IDX if listings are shown publicly, VOW if visitors must sign in, or a private plan for back office use. Read the plan terms and pricing.
Buying the plan starts an email approval chain with the MLS. Spark says issuing keys is up to each MLS.
The sync is built against the demo credentials and moved to the live key once the MLS approves.
Spark's RESO Web API docs cover replication in detail. These points shape the sync.
01Keys with replication access must call replication.sparkapi.com. The same requests fail on the regular RESO endpoint.
02Replication raises $top to 1,000. Spark recommends following @odata.nextLink, which pages by ListingKey through $skiptoken, over $skip, which can return the same listing twice.
03Changes are found with a $filter on ModificationTimestamp, using both a lower and an upper bound.
04Removed listings are found by pulling every ListingKey and deleting local records that are not in the list. Spark says to do this at least once a day.
05Media, Room, Unit and OpenHouse can come with the listing through $expand. PhotosChangeTimestamp, VideosChangeTimestamp and DocumentsChangeTimestamp show when to fetch them again.
061,500 requests per five minutes for an IDX key and 4,000 for VOW and back office keys. Every call counts, nextLink pages included, and Spark makes no exceptions.
Spark was not on the platform we ran. These are the things the RESO Web API standard itself brings, and what our sync engine already does with each of them.
Token, metadata, filtered pulls and nextLink paging work the way they do on every RESO Web API feed we have run.
Local fields, lookups and status values differ by MLS. Each one gets its own small filter class on top of the shared parser.
A daily purge removes what left the feed. If the feed returns too few IDs, the purge is skipped and we get an alert.
IDX opt out flags and per listing address hiding are honoured, and each board's disclaimer shows the last updated time.
The bearer token does not expire, so it lives as a server side secret and is never used from the browser. The sync runs from a server cron job and keeps an IDX key under 1,500 calls in any five minutes, nextLink pages included. Listings go to their own tables for pages to query.
Scheduled queued jobs handle changes, the daily ListingKey purge and media refreshes driven by the change timestamps. A rate limiter set to the key's five minute allowance sits in front of every call, and the replication base URL is kept in config apart from the regular one.
The RESO endpoint suits a site that may add other feeds later, because it shares field names with them. If you need Flexmls extras like saved searches or market statistics, the Spark API carries those, and both use the same key.
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 Spark access, 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.
Spark is the route for MLSs on Flexmls. If your MLS is also on another platform, the choice comes down to the plan price in the Datamart against the other platform's fees, and whether the request limits fit your market.
Spark's limits are counted per five minutes and cannot be raised. For a large MLS that makes the first full load slower to pace. For a single brokerage site that only pulls changes, the allowance goes further.
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.