Developer Documentation
Platform Overview
Authentication
API Services
Overview Accounts Accounts: Associations Accounts: Metadata Accounts: Profile Appstore: Users Broker Distributions Broker Tours Consumers Consumers: Linked Agents Contacts Contacts: Activity Contacts: Export Contacts: Tags Contacts: Portal Accounts Developers: Identities Developers: Keys Developers: Authorizations Developers: Billing Summary Developers: Change History Developers: Domains Developers: News Feed Webhooks Developers: Roles Developers: Syndications Developers: Templates Developers: Usage Detail Developers: Usage Summary Devices Flexmls: Email Links Flexmls: Listing Meta Origins Flexmls: Listing Meta Translations Flexmls: Listing Meta Field List Translations Flexmls: Listing Reports Flexmls: Mapping Layers Flexmls: Mapping Shapegen IDX IDX Links Listing Carts Listing Carts: Portal/VOW Carts Incomplete Listings Incomplete Listings: Documents Incomplete Listings: Documents Metadata Incomplete Listings: Document Uploads Incomplete Listings: Floor Plans Incomplete Listings: FloPlans Incomplete Listings: Photos Incomplete Listings: Photos Metadata Incomplete Listings: Photo Uploads Incomplete Listings: Rooms Incomplete Listings: Tickets Incomplete Listings: Units Incomplete Listings: Videos Incomplete Listings: Videos Metadata Incomplete Listings: Virtual Tours Incomplete Listings: Virtual Tours Metadata Listings Listings: Clusters Listings: Documents Listings: Documents Metadata Listings: Floor Plans Listings: FloPlans Listings: Historical Listings: History Listings: Notes Listings: Search Parameters Listings: Open Houses Listings: Photos Listings: Photos Metadata Listings: Photo Uploads Listings: Document Uploads Listings: Rental Calendar Listings: Rooms Listings: Rules Listings: Tour of Homes Listings: Tickets Listings: Units Listings: Validation Listings: Videos Listings: Videos Metadata Listings: Virtual Tours Listings: Virtual Tours Metadata Listing Meta: Custom Fields Listing Meta: Custom Field Groups Listing Meta: Field Order Listing Meta: Field Relations Listing Meta: Property Types Listing Meta: Rooms Listing Meta: Standard Fields Listing Meta: Units Registered Listings Market Statistics News Feed News Feed: Curation News Feed: Events News Feed: Metadata News Feed: Restrictions News Feed: Schedule News Feed: Settings News Feed: Templates Open Houses Overlays Overlays: Shapes Portals Preferences Saved Searches Saved Searches: Provided Saved Searches: Restrictions Saved Searches: Tags Search Templates: Quick Searches Search Templates: Views Search Templates: Sorts Shared Links System Info System Info: Languages System Info: Search Templates
Supporting Documentation
Examples
RESO Web API
RETS
FloPlan
Terms of Use

Spark® API

The Spark API allows authorized MLS members to request data through developer applications according to the permissions and license requirements of the MLS.

 
 
 

What Data Is Available Through the API?

There are three main categories of data available through the API: Listings, Contacts and Market Stats. The access level to each data type is dependent on the role assigned to each user. For example, members of the MLS can access more listing information than consumers on an IDX web site. More information on roles is here.

 
  • Standard fields – Each listing is standardized according to the RESO Data Dictionary to the extent possible currently. All standardized fields are searchable if allowed by the MLS for your role.
  • Custom fields – Fields not able to be standardized are available as custom fields. Our expectation is that developer innovations will incentivize MLSs to standardize more and more of their data over time.
  • Listing Photos
  • Open house info
  • Agent tour info
  • Documents/Disclosures
  • Virtual tour and video links

Average and median stats by location (city, zip, etc.) for:

  • List prices
  • Sale prices
  • Sale/List prices
  • Days on Market
  • Absorption Rate
  • Inventory
  • Volume
 

Back to Top

 

Role-Based Access to the API

The API only allows access to data by authorized members of the MLS according to roles set for each user by the MLS through the API Manager in the Platform. In this way, the MLS maintains control of what data each user is able to see through the API and what permission each user has for using the data.

Software Application to API Data Based on Member Role to MLS Member
 
 

API Manager Defines Roles for the API

There can be many different roles for MLS members, but the three most important roles defined by the MLS through the API Role Manager are:

 
MLS to MLS Members VOW to Customers IDX to Consumers
 
 

What is the MLS Member Role?

The API also allows developers to create applications for MLS members with authority to see the entire MLS database. In other words, using the API, developers can create the same types of applications used by MLS members in the private MLS system.

Example applications:

 

What are the IDX and VOW Roles?

The IDX and VOW roles allow authorized MLS members to share listing information with consumers on their web sites or applications and customers who login to the web site or app.

IDX is for Consumers. IDX stands for Internet Data Exchange and is an MLS policy that allows authorized MLS members to display designated MLS information on their web sites and mobile applications to consumers (web site visitors).

VOW is for Customers. VOW stands for Virtual Office Website and is an MLS policy that allows authorized MLS members to display designated MLS information on their web sites and mobile applications to their customers. The difference between IDX and VOW primarily is that VOW access requires the consumer to identify themselves and login to the MLS member’s web site or application (their virtual office). Once the consumer is identified and logged in to the MLS member site or app, they can see more information (including sold information) than is available through the IDX role.

Example applications:

Back to Top

 

Authentication

Each request to the API requires two forms of authorization, one from the developer and the other from the MLS member. If either the developer or the MLS member is not authorized to access the API, the request is not allowed. With two forms of authorization, each API request is able to identify the software developer, the developer's application, the end user, and the MLS, and in the case of the VOW role, the agent with whom the end user is working.

End Users -- Private and VOW roles require that the end user, an MLS member or VOW customer, enter a username and password to identify, authenticate, and authorize their active membership in the MLS or their VOW account. The authorization step shows the API that the end user has granted permission for the API requests to occur on that user's behalf. Requests to the API for IDX data require the application to provide an access token that both identifies the developer and the developer's application, and provides proof to the API that the MLS member has personally authorized that application to access data on their behalf and provide that data to IDX visitors. When IDX applications are purchased, the MLS member must authorize that application to access their data.

All forms of authorization used in the API use OAuth 2, a standard that allows authorization to be granted without requiring software developers to store end users' usernames and passwords in their applications, increasing the security of the Platform.

At the time of authentication, users are required to agree to the appropriate Terms of Use.

Back to Top

 

Clear and Consistent Licensing and Terms of Use

Another core focus for the Spark Platform is to ensure that the data and software are licensed under clear and consistent terms of use all the way from the MLS through to agents and their customers.

Terms of use are required to be agreed upon when users license applications through the Store and also when they login to use applications. The authentication process identifies the role or permission level available to that user and instructs the API what data may be provided. The MLS is able to control the data available to each role through the API Manager.

In this way, the license and terms of use for both the MLS data and the software is agreed to consistently by every user gaining access to the data through the API.

Back to Top

 

Implementing Data Standards

One of the core objectives for the Spark Platform is to help MLS organizations implement the Real Estate Standards Organization (RESO) data dictionary being developed.

One of the obstacles historically to implementing data standards was the lack of immediate incentive. Most everyone understands the long-term incentive for more standardized data (lower cost and increased interoperability of software), but those benefits are so long-term that they make action today difficult.

The Spark Platform attempts to address this challenge by creating an economic eco-system that encourages MLSs, brokers and developers to work together to promote more data standards. As FBS brings in data from participating MLSs, the data will be mapped into the RESO standard fields using a Data Field Mapper we’ve created. This software will help both FBS and each MLS work together to continually add more standard fields as they are needed by new applications being created by developers.

Fields not able to be mapped to a standard field currently will still be supported in the API as custom fields. In addition, the API supports localization of the data labels even on standard fields, including the ability to represent the fields in multiple languages. However, all standard fields will be able to be searched through the API by the RESO standard field.

FBS has long been a strong proponent of data standards for the MLS industry and we will continue to work with RESO to expand the data dictionary. As the data dictionary expands, we will be able to map additional fields to the standard fields, with the constant objective of mapping as many fields as possible to the standards.

Back to Top