Developer Documentation
Platform Overview
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: Listing Updates Flexmls: Mapping Layers 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: 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: 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 Messages 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 Properties Properties: Clusters Properties Meta: Standard Fields 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
API Explorer
Supporting Documentation
Terms of Use

RESO Web API Replication

If you'd like to replicate data and are not sure if you've been provided a key for replication, or find a problem with this outline, please contact

  1. Replication
  2. Guidelines
    1. Initial Download
    2. Update Data
    3. Purging Stale Data


The RESO API endpoint for replicating data is: Developers replicating data must use this endpoint.

Developers who wish to replicate data are granted Personal Access Tokens with special replication access. These keys are granted a few additional privileges to make replicating data easier. For example:

  1. The maximum $top value is raised to 1000 records.
  2. The Members and Offices resources do not apply company or office restrictions when searching user records for IDX roles.

These keys are otherwise identical to regular API keys, with access to the same resources and governed by one of our data roles.



The following guidelines outline the process for replicating using our implementation of the RESO Web API. While the Properties resource is used in these examples, the same general guidelines also apply to replicating other resources like Member and Office.


1. Initial Download

To kick off the initial download you"ll need to make a request to the all properties endpoint. Optionally, you may include the $count or $select parameters, but no other parameters should be specified.

Paginating through the full result set can be accomplished by executing the request returned by the @odata.nextLink value in your last request. This attribute shows how to access the next page of results using the $skiptoken parameter when you've finished processing the current page.

Important: a ListingKey orderby is applied by default, ensuring that the order of the results is consistent while paginating with _skiptoken.


2. Update Data

Keeping your result set updated involves making requests against the ModificationTimestamp field using the timestamp of your last successful update minus 20 minutes to account for server side caching. Here is a pseudocode example to demonstrate:

query_timestamp = last_successful_retrieval_timestamp - 20 #minutes
?$filter=ModificationTimestamp gt query_timestamp

Paginating through the update result set is once again accomplished by following the @odata.nextLink attribute.

During this step it is recommended that you also update the Media, Room, Unit and Open House relations. For an optimization, when updating media for a listing, you can reference the PhotosChangeTimestamp, VideosChangeTimestamp and DocumentsChangeTimestamp attributes to see if any media needs to be updated prior to polling for that data.


3. Purging Stale Data

Repeat step 1 with the $select=ListingKey parameter applied, paginate through the result set identically to step 1, and compare all ListingKey values returned with the values in your database. Purge any records that do not match.