REALTOR.ca DDF® Documentation

An email containing user name and password is sent to the email address submitted as Technical Contact when data feeds are registered in https://ddf.realtor.ca/. The owner of the data feed can view credentials when editing the feed on the Data Feeds page.

When doing an HTTPS GET request to the server, the Query value needs to be URL-encoded. Failure to properly encode can potentially cause rejection of the entire request, or incorrect responses from the server. For example, instead of sending Query=(ID=0+), use Query=(ID=0%2B). Instead of sending Query=(ID=1234,5678), use Query=(ID=1234%2C5678).A complete URL encoding reference can be found here:
http://www.w3schools.com/tags/ref_urlencode.asp

Common RETS clients, such as libRETS, may not support Standard-XML format for search results, which is the only format available from CREA’s DDF® Data Feed.

CREA’s DDF® Data Feed supports a limited set of queries. Users wanting to filter search results must be configured when registering/editing the data feed in the setup of the feed.

ID is the unique identifier for the property within CREA’s system. This is the key that should be used when querying DDF® for a specific property. ListingID is the well-known identifer (e.g. MLS #) for the property that is typically generated in originating local board/association system. Since the property data being retrieved can potentially come from multiple originating systems, there is potential for the same ListingID to belong to multiple properties, so ListingID value should be used only for display purposes, and not as an identifier in DDF® client systems.

The sample code download contains a complete Visual Studio 2010 solution coded in either C# or VB.NET. If you are using an earlier version of Visual Studio, you should be able to copy the code from DataFeedExample.cs or DataFeedExample.vb into a blank Visual Studio solution and compile successfully. The app.config contained in the solution should also work without changes in older versions of Visual Studio.

CREA’s DDF® Data Feed runs as a Windows Communication Foundation (WCF) service, with a set of URI templates describing the parameters supported (e.g. Resource, Culture, Format). If a request is received that matches none of the defined templates, the service has no way of understanding what the request is asking, so replies with “HTTP Method not allowed”. If you receive a response like this, review the URI in your request and make sure you the URI is correct, and that all required arguments are included.

What am I doing wrong?

A “Not Logged In” error being returned after a successful Login is likely occurring because you are not including the X-SESSIONID cookie that was set in your Login response. This X-SessionID value needs to be submitted with every request after logging in. CREA’s DDF®Data Feed validates that the X-SessionID and credentials match on every request, so if its missing, you’ll get a “Not Logged In” response.The RETS 1.7.2 specification requires clients to include any cookies set by the server:

http://www.reso.org/specifications (See section 3.3 Required Client Request Header Fields)

This reply code occurs when an invalid Format argument is included in the request. Standard-XML is the only supported format. The server should default to this if the argument is not included (as our documentation suggests). Unfortunately, it currently treats it as a required argument. This will be corrected in an upcoming release, so that Format is no longer mandatory.

This reply code occurs when an invalid Format argument is included in the request. Standard-XML is the only supported format. The server should default to this if the argument is not included (as our documentation suggests). Unfortunately, it currently treats it as a required argument. This will be corrected in an upcoming release, so that Format is no longer mandatory.In general, RETS Metadata lookup tables provide a list of fields that can be used for 2 purposes:

1. building queries (e.g. return all properties in the $300K-$500K range, with 3+ bedrooms)
2. indicating which fields the user would like returned (e.g. return only Address, Price and BedroomCount for each listing)

By design, CREA’s DDF® service does not allow ad-hoc querying. Clients are expected to pull all listings available to them, and not choose a subset at runtime. If the registered owner of the destination wants filters applied to their data feed, they can be configured in the DDF® dashboard (https://ddf.realtor.ca/). The only value that can be directly queried is the ID field for each resource type.

CREA’s DDF® service also does not allow clients to customize the data included in the response. All DDF® clients receive the same Standard-XML data payload. The RETS Select concept that users can pick and choose which value to include is more practical when providing Compact (i.e. tabular) data, which is not supported. Since clients cannot customize the format of the results, data fields are not required in metadata calls.

Alberta West REALTORS® Association
Association Of Regina REALTORS® Inc
Barrie & District Association of REALTORS® Inc.
BC Northern Real Estate Board
Brandon Area REALTORS®
Brantford Regional Real Estate Assn Inc
Calgary Real Estate Board
Central Alberta REALTORS® Association
Chilliwack & District Real Estate Board
Cornwall & District Real Estate Board
Fort McMurray REALTORS®
Grande Prairie & Area Association of REALTORS®
Guelph & District Association of REALTORS®
Huron Perth Association of REALTORS®
Kawartha Lakes Real Estate Association
Kingston & Area Real Estate Association
Lethbridge & District Association of REALTORS®
London and St. Thomas Association of REALTORS®
Medicine Hat Real Estate Board Co-op
Mississauga Real Estate Board
Newfoundland & Labrador Association of REALTORS®
Niagara Association of REALTORS®
North Bay and Area REALTORS® Association
Northumberland Hills Association of REALTORS®
Ottawa Real Estate Board
Peterborough & Kawarthas Association REALTORS®
Quinte & District Association of REALTORS® Inc.
Real Estate Board Of Greater Vancouver
REALTORS® Association of Edmonton
REALTORS® Association of Grey Bruce Owen Sound
REALTORS® Association of Lloydminster & District
REALTORS® Association of South Central Alberta
Renfrew County Real Estate Board
Rideau - St. Lawrence Real Estate Board
Saskatchewan REALTORS® Association
Simcoe & District Real Estate Board
Southern Georgian Bay Association of REALTORS®
The Lakelands Association of REALTORS®
The Oakville, Milton & District Real Estate Board
Vancouver Island Real Estate Board
Victoria Real Estate Board
Waterloo Region Association of REALTORS®
Winnipeg Regional Real Estate Board
Woodstock Ingersoll Tillsonburg and Area Association of REALTORS® (WITAAR)

As a way to save your business time and money, we’re changing how you pull photos from DDF® to power your websites.  As a result, support for streaming images through the GetObject function of the Object service will be discontinued as of July 6, 2020. 

How will I pull photos? 

The DDF® payload will now expose the image URLs for all three photo types: 

•ThumbnailPhotoURL (low resolution); 

•PhotoURL (medium resolution); and

•LargePhotoURL (high resolution).

What does this mean for my business? You will now have two options to retrieve photos from DDF®: 

1.   Store the URLs in your system and embed them directly into your websites. The benefit of this method is not having to download and store every possible listing image for every customer’s site. This will also allow you to manage your DDF® better feeds by reducing the time needed to keep the feeds in sync and removing the need for large amounts of file storage. This is the recommended approach for most DDF® clients. 

2. You can also download images using the URL instead of streaming through the GetObject function of the Object.svc and continue storing photos within your system. 

What happens if I don’t make the change by July 6, 2020? 

If you don’t make any changes, your websites will not receive any photos from DDF®.