Transitioning to WebAPI FAQ for vendors and developers

General Transition Questions:

  • What is WebAPI, and how does it differ from RETS? 

    WebAPI and RETS (Real Estate Transaction Standard) serve the same purpose of facilitating real estate data exchange but differ significantly in technology and efficiency. More detailed information can be found  at https://www.reso.org/reso-web-api/

Key Differences:

Technology: RETS uses XML-based files, an older, heavier data format that requires substantial storage and creates high maintenance costs. WebAPI uses RESTful principles, which are lightweight, widely adopted, and operate using HTTP, making it more efficient.

Data Access and Integration: RETS requires local database replication for data storage and updates, creating storage and synchronization challenges. In contrast, WebAPI adds the option of direct queries to MLS databases, offering real-time data access without local duplication.

Security and Scalability: WebAPI incorporates modern security protocols, better safeguarding sensitive real estate data. It is also more scalable and adaptable across web and mobile platforms, promoting easier industry adoption.

Industry Transition: As the real estate industry moves towards RESO WebAPI, it’s replacing RETS due to WebAPI’s modernity, ease of use, and alignment with current digital standards.

  • Why is the transition from RETS to WebAPI necessary? 

    The transition is driven by the deprecation of the current RETS system by its provider, which is outside of our control, and the need for enhanced data efficiency and compliance.

  • What platform will you be using to offer WebAPI?  

    We will be using the BridgeAPI platform provided by Bridge Interactive.

  • What is the cutoff date for transitioning to WebAPI/BridgeAPI? 

    The cutoff date to complete the transition is February 28, 2025, after which the RETS platform will no longer be available.

  • Will the old RETS system be accessible after February 28, 2025? 

    No, the old RETS platform will be fully deprecated, and WebAPI/BridgeAPI will be the sole platform in use.

  • How will the transition affect my current data access? 

    Your current data access via RETS will be fully replaced by WebAPI/BridgeAPI after the cutoff date. Planning your migration early will ensure a seamless transition.

Onboarding and Access Questions:

  • What information do I need to provide to begin the WebAPI/BridgeAPI onboarding process? 

    If you are not already using the BridgeAPI platform in other markets you need to provide your contact email and RETS username. Invitations to the Bridge platform will be sent out soon to facilitate onboarding.

If you are already using the BridgeAPI platform, you can apply for data access under the “Data Access” tab then “Request Data Access” tab in your account.  Ensure that you are requesting data access on the correct application if you have multiple. Our organization appears as “Greater Vancouver REALTORS®, Fraser Valley Real Estate Board, Chilliwack and District Real Estate Board, BC Northern Real Estate Board – Residential”

If the platform invitation was sent to a different email address from your primary Bridge account, you can find the instructions on how to merge here. https://www.bridgeinteractive.com/how-to-merge-your-bridge-accounts/

  • How will I receive my Bridge platform invite? 

    Invites will be sent to the provided email addresses as soon as the data feed setup is finalized.

  • What should I do if I miss the February 28, 2025 deadline? 

    Missing the deadline could result in service interruptions, as the RETS platform will no longer be available. We highly recommend beginning your migration as soon as possible to avoid any issues.

Technical and Development Questions:

  • Can I still use RETS on BridgeAPI?  

    Yes, BridgeAPI offers a product called Virtual RETS. This may allow you to use your exiting RETS client/tools as long as they are compliant with RETS 1.9. It potentially replicates your current workflows but is intended as a temporary solution. We strongly encourage transitioning to WebAPI for long-term use.

Things to note about vRETS. 

There are some breaking changes in RETS 1.9 that your RETS client and other tools may not have implemented. 

vRETS is based on the schema in BridgeAPI, so although the tools may stay the same using this solution, you will still need to put significant work into consuming the updated schema. 

  • Will there be any changes in the data format with the new WebAPI/BridgeAPI platform? 

    The data format will be aligned with modern standards set by RESO Data Dictionary where possible, ensuring better compliance and consistency. It’s important to review the API documentation for any changes that might affect your current integration.

  • What are the RESO Data Dictionary standards, and how do they affect my data? 

    The RESO Data Dictionary is the real estate industry’s universal language for data. It empowers a wide range of systems to talk to each other in a seamless manner. The Data Dictionary provides a format for industry standard data, unique local data, international variations and language translations. Localized fields will follow the BCRES_ prefix for residential data and the BCCLS_ prefix for commercial data. More information about RESO Data Dictionary can be found at https://www.reso.org/data-dictionary/

  • Where can I find technical documentation for WebAPI/BridgeAPI? 

    You can access the BridgeAPI Documentation for all technical details, including how to integrate and work with the new system.

  • Who do I contact if I encounter issues during the transition or onboarding? 

    For issues or questions related to GVR/FVREB/CADREB/BCNREB data/data feeds or onboarding you can contact idx@gvrealtors.ca

For platform related questions and issues, you can reference the documentation provided above or contact the BridgeAPI support team at support@bridgeinteractive.com

Other Changes to the Data and Data Feeds:

Geocode Data 

A key project this year involved enhancing our geocode data specifically for the transition to BridgeAPI. Due to licensing constraints, we cannot provide latitude and longitude data where the Boards do not own the data. While we have required manual pin placement for some time, many historical listings still carry this restriction. We’ve backfilled a significant portion of the database with open-source data, making geocode data available on most listings. Unfortunately, a small percentage of listings couldn’t be backfilled. 

We introduced a new field, BCRES_IsManualGeocode, to indicate whether geocode data is included. A False value signals that you may need to geocode these listings independently. We hope this enhancement will reduce operational costs for vendors/data consumers and improve the end-user experience.

Transitioning to Relational Data 

Where possible, we are separating agent, office, and other related data from the listing records and are providing more information in the agent and office resources. This approach should ensure the most up to date office and agent information is available.

Due to privacy concerns, we’ve implemented a filter to exclude agent email addresses when no active listings are associated with them. We’ll be updating our guidelines and policies to reinforce restrictions on displaying email addresses and we remind vendors/data consumers of the prohibition on using this data for solicitation.

You can utilize the $expand feature for ListAgent, CoListAgent, ListOffice, CoListOffice, and OpenHouses.

Currently, the RESO-compliant rooms resource hasn’t been incorporated as it requires extensive updates to our native system. For now, we’ve included custom fields to replicate our previous schema. 

Mapping Documentation 

Finally, to assist with data conversion, the Bridge platform enables vendors/data consumers to download a comprehensive mapping document showing current and previous field names. Please note, this file includes every available field, including those we aren’t using in our feeds. A separate document to narrow down the relevant fields specifically for the IDX and VOW data feeds is available upon request. Email idx@gvrealtors.ca 

Combined Feed Types for VOW data feeds 

Bridge offers a useful “Combined Feed Types” feature. For VOW vendors/data consumers, we’ve included both IDX and VOW data feeds. Accessing the IDX API endpoint will retrieve approved IDX data, whereas the VOW API endpoint will return approved VOW data. 

The standard API endpoint will display all listings, with a new “FeedTypes” field indicating whether each listing is governed by IDX, VOW, or both policies. This should streamline compliance with Board display policies and reduce reliance on the spreadsheets we’ve traditionally maintained.  More details are available in the API documentation