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: Listing Updates 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 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
Examples
RESO Web API
RETS
FloPlan
Terms of Use

Best Practices: Photo downloads

The below outlines some of the best practices for retrieving real estate listing photos from the flexmls RETS server.

 

Hot-link our photos whenever able.

Our RETS server supports the Location=1 parameter through GetObject which means that, rather than you downloading and maintaining the entire collection of listing photos on your servers, you can instead simply get back the URL to our hosted versions of the photos and link to them directly from your application. Instead of maintaining many GBs worth of images, you'd instead manage a list of photo URLs per listing. The photo URLs given back point to a distributed CDN for fast delivery to your end users.

 

Be aware of which RETS version you're using and how querying by timestamps work in that version.

When using RETS version 1.5, the timestamps you supply in your queries are assumed to be in GMT. When using RETS version 1.7.2, the timestamps you supply can contain additional timezone offset information; however, if that timezone offset information is missing (making the timestamp look identical to the format used in RETS 1.5), the timestamp is assumed to be in server local time. For more information on how timezones work, see this write-up along with the examples.

 

Use RETS 1.7.2 if able

Related to the above, being able to specify the desired timezone makes things much clearer. If your process expects to send timestamps in GMT, simply add a "Z" to the end to tell the server that this is a GMT timestamp. For example: (LIST_134=2013-03-01T12:31:00Z+)

 

Detect which listings to re-retrieve photos for based on the photo modification timestamp field -- not the data modification timestamp field.

On the flexmls RETS server, the photo modification timestamp field is LIST_134. If you're detecting changed photos by looking at LIST_87 (the data modification timestamp field), you're downloading more photos than needed.

 

Query based on the highest timestamp you've previously seen

In order to pull photos for only those listings which have had recent photo changes, you'll need to track a timestamp to use for your incremental queries. Track this query based upon the highest LIST_134 timestamp seen during your previous processes. This allows your process to better withstand failures which could ultimately result is missed photo updates. Remember that the timestamps returned by the server are in server local time (typically Central time from the flexmls RETS server).

 

Choose the appropriate photo size for your use.

 

Select the size that best meets your needs and resize down if necessary. This goes into your request as the Type parameter.

 

If you only need the primary photo, request ":0"

If you're only interested in getting the main photo for a listing, making a request like the one below will only give back the photo marked as the primary. flexmls Web allows for any photo to be marked as primary so this may not be the same as the 1st photo in the list.

 
http://retsgw.flexmls.com/rets2_3/GetObject?Resource=Property&Type=HiRes&ID=352918:0&Location=1