SimplyRETS https://simplyrets.com/atom.xmlChristopher Reichertchristopher@simplyrets.com2017-06-03T00:00:00ZHow we use Assertible to test the SimplyRETS API and websitehttps://simplyrets.com/blog/how-we-use-assertible-to-test-the-simplyrets-api-and-website.html2017-06-03T00:00:00Z2017-06-03T00:00:00Z

Behind the scenes at SimplyRETS, we focus a lot of our effort on testing to make sure our API, website, and other web services are always functioning properly. Our infrastructure relies heavily on continuously testing at each step of the development process. One of the tools we rely on the most is Assertible, a tool for testing and monitoring APIs and websites. We use Assertible to monitor and continuously test our API, website, blog, and any other web services in our infrastructure.

One reason we love Assertible is that it integrates directly with GitHub and utilizes these hidden features to improve the experience of building web services.

Every time we push code to a pull request we deploy the changes to a staging environment. Immediately after the code is deployed, Assertible runs API integration along with functional website tests against the staging environments. When the tests are finished running, we can view the statuses directly on our pull requests. Additionally, the Assertible Deployments API creates links directly to our deployed web services so we can jump to them for review and sharing:

Because of this strategy, we don’t have to worry about manually testing old features which allows us to focus on the features we are currently building without breaking something. While we also use unit tests extensively, we rely heavily on Assertible for integration testing and functional validation of our API release candidates.

Scheduled monitoring

Scheduled monitoring is another critical component of our continuous testing strategy. We run our tests on scheduled intervals to monitor performance and availability to ensure everything always works and is not causing bugs for users. The same test-suites are reused in the post-deploy step mentioned above.

Scheduled API monitoring and website monitoring has several advantages over post-deploy testing alone:

Ability to validate and test data that constantly changes

Identify regressions that take time to manifest (e.g. background jobs that change the database)

Continuously monitor for downtime across a wide array of endpoints

Continuously monitor for functional defects that aren’t picked up by more simple monitoring services like Pingdom.

We believe that scheduled monitoring is a critical piece of the puzzle and helps us track down bugs before our users hit them!

Add tests for all new bugs or regressions

As part of our overall continuous testing strategy, we rigorously add new tests every time a new bug or regression is uncovered. Because we end up adding tests often, we follow some simple guidelines to ensure the tests aren’t flaky and constantly blowing up our alerting system:

Create the smallest test possible

This generally means confining the test to validate a single feature, regression, or bug.

Test a single specific interface

This is straight forward in our infrastructure. We limit our tests to a single interface and try not to make tests that rely on several services, when possible.

Avoid allocating blobs of data

This goes along with creating the smallest test possible. We’ve found that tests which rely on allocating too much data become flaky. While this is necessary sometimes, it’s important to only allocate the data that’s absolutely necessary to test a single thing.

Refactor or remove old flaky tests

Testing is hard. Often, tests can become flaky or raise false-positives often. Because of this, we refactor and/or remove tests which are causing constant problems. When possible, we try to add tests at the unit testing level.

At SimplyRETS, we try our best to make using our API and services a simple and pleasurable experience. This article describes some simple tips geared towards maximizing the stability and performance of your SimplyRETS application.

1. Always use explicit media-types

(e.g. Content-Type header).

It’s very important to always explicitly specify a Content-Type header in API requests. By default, our API and services honor the Content-Type: application/json header as the default and latest version of our API resources.

The downside to always using the latest media type is that as we improve and upgrade our API, you may experience unexpected changes. For example, changes to the JSON keys or the type of a field may change when we make a change. Specifying an exact media type version can prevent this from happening.

To view accepted media types, make an OPTIONS request to the root url endpoint:

The accepts field in the returned JSON object is a list of supported ‘Content-Types’ (e.g. what the SimplyRETS server will accept.

To always retrieve the latest formats supported by SimplyRETS:

application/json

WARNING If you don’t explicitly set a media type (or use application/json, your app may be at risk of breakage when fields in the API are upgraded). This is also explained in our interactive documentation

To explicitly specify a media-type, use a Content-Type with `vnd.simplyrets-v0.1+json.

application/vnd.simplyrets-v0.1+json

The v.0.1 is the SimplyRETS API version. When new versions of the API are released, your application will be backwards compatible with v0.1.

/If you are using the WordPress Plugin, the Content-Type header is set automatically/

2. Use narrow API queries

SimplyRETS supports a wide range of query parameters for listing data. If your aiming for performance, it’s important to keep your queries as narrow as possible.

For example, if you need to find 4 bedroom active residential homes,

https://api.simplyrets.com/properties?minbeds=4

The default property types searched in this query is Residential and Rental. Active and Pending listing statuses are queried by default. This means our query is doing a little more work than necessary.

The most efficient and performant way to specify the query is to use explicit parameters for each criteria:

It may not always possible to narrow the criteria down this far but it can have worthwhile benefits.

3. Use the support form in the SimplyRETS admin panel

We use a support email support@simplyrets (support at simplyrets dot com) to handle general support inquiries. We are more than happy to provide top-tier support over email. There is a trick, however, to having your technical issues prioritized directly with our development team.

The quickest way to have your support request reviewed by our development team is to submit it using the Support Request form in the admin panel.

We are enhancing our support request process so we can resolve issues as fast as possible. Keep in mind, if you are having technical problems, it is a good idea to include the following details:

Your query string, even if the query seems obvious

Steps to reproduce

The output you are receiving

The output you expect to receive

In general, including more information helps us narrow down possibilities significantly quicker and will help you get the answer you need directly for our development team.

4. Request Listings Directly

Whenever possible, use the mlsId field to request listings directly. Remember, mlsId is the unique identifier specific to SimplyRETS. Think of mlsId as synonymous with ListingKey from the RESO Data Dictionary

For example, when dealing with a listing which has the following attributes:

{
...
, "mlsId": 1238453
, "listingId": N3487923
...
}

using the mlsId to directly request the listing

https://api.simplyrets.com/properties/1238453

will be significantly more performant than

https://api.simplyrets.com/properties?q=N3487923

WARNING: A drawback of requesting listing directly is that SimplyRETS cannot predict when the MLS will purge them from the database. Most of the time, it’s best not to hardcode mlsId queries (e.g. for featured listings). Rather, structure your code to make use of the mlsId when possible.

5. Understand listing status and purging

Each day, SimplyRETS deletes old listings from your feed. Old listings are those which your MLS has revoked access and requested it be removed from our servers. This could be because the listing was sold, deleted, or even withdrawn or cancelled.

For example, imagine there is a listing in your feed with an mlsId of 12345 and status Active.

{
...
, "mlsId": 12345
, "status": "Active"
...
}

Tomorrow, when requesting the listing, the response returned for the same listing will be an HTTP 404 response status.

Even if your account has access to Closed, Withdrawn, or even Terminated listings, you may still experience listings being purged at any given point.

Map real estate search apps are a great way to enhance web app functionality and user-engagement. They can be significantly more user-friendly to use for real estate listing search utilities than standard html forms. Many features in the SimplyRETS API are built with this specific use-case in mind.

For the uninitiated, SimplyRETS leverages your RETS feed to offer tools and services for developing beautiful real estate software using your listing and open house data. Our services are designed to be simple and effective for any developer to use productively.

In this tutorial, I’ll outline how to build a simple map-based search app using the SimplyRETS API. If you want to skip to the code or follow along with a complete sample, you can use our Github Examples Repo.

The primary feature in the SimplyRETS API which helps with map-based searching is the points query parameter. The points parameter is simply a list of latitude/longitude coordinates (separated by a comma). See our interactive documentation for more details and other query parameters.

Note that points is specified once for each point in a polygon made up of latitude/longitude coordinates.

In order to utilize the points parameter from a web app, we need a few external utilities and libraries for rendering maps on html/javascript pages. I’ll be using Leaflet and OpenStreetMap as a starting point to build the map and access basic map tools. We will also be using a Leaflet extension called Leaflet.Draw

I will use jQuery to make some of the Javascript more simple. However, jQuery is not strictly necessary for this app.

All the tools used in this tutorial are free and open source. You are free to download and use them in your own projects. I have also included the source code for this tutorial on our Github. if you’d like to follow along or reuse it.

Once the foundation is laid, I’ll make API calls to the SimplyRETS listings endpoint, https://api.simplyrets.com/properties, using javascript to retrieve the listing data and populate the map.

The end result of this tutorial should be a simple mapping application which can be adapted for use in many different situations. You can check out a live demo here.

Getting Started

To get started, create a file named index.html and include an html page shell.

This html is enough to get started. You can open this file directly in a web browser (without a web server). Type file:/// in your address bar to navigate to the right folder. Don’t worry if the page is all white yet.

Include Dependencies

Next, we need to include some scripts and stylesheets in order to use Leaflet, OpenStreetMap, and jQuery. For the purposes of this tutorial, I will use CDN links. It’s not necessary to download any code manually.

Javascript

Now that we have our project setup and a code skeleton to work with, we can start writing some javascript to implement our map logic.

$(document).ready(function() {
// Code goes here.
});

This line of jQuery code ensures that the web page is ready to be manipulated. jQuery handles the details for us. Anything inside the ready(function() { code block will be executed once when the DOM can be manipulated.

The capital L is an identifier for the Leaflet namespace. Functions called after the L. are specific to the Leaflet API. In this case, we are initializing a map, then creating a tileLayer which we add to the map. In short, Leaflet applications work by manipulating various layers within the context of a map.

The tile layer on our map is backed by an OpenStreetMap tile png. The maxZoom is set to 18. The higher the maxZoom, the further away the the map will be allowed to zoom out. The final addTo call is where the tile layer is directly associated with the map object.

We use the latitude/longitude coordinates of Houston, Texas to center the map since the SimplyRETS test data is located in Houston.

var houston = new L.LatLng(29.97, -95.35);
map.setView(houston, 13);

L.LatLng is another convenience class which the Leaflet API provides. A LatLng object can be applied directly to the map as a view using setView. The second argument to setView is the initial zoom. 13 is a good enough value to see the entire city.

Drawing on the Map

In order to draw Polgons on the map, we need to set up a Leaflet FeatureGroup. FeatureGroup’s are another Leaflet class capable of grouping and interacting with other layers on the map. Using FeatureGroups, we can add our polygon(s) to the map using only a few lines of code.

We set up a basic feature group name drawnItems (for drawn items) and add it to the map using addLayer.

var drawnItems = new L.FeatureGroup();
map.addLayer(drawnItems);

Now, we need to attach the same drawnItemsFeatureGroup to a Draw control.

We created a new Draw control, using our FeatureGroup for drawn items. To connect the Draw control with the map, we use the map.addControl function call (similar to map.addLayer).

If you load the map now, you will see a control panel in the upper left corner:

For the purpose of this tutorial, we focus on the square and polgon tools. Using the draw options when creating the Draw control, we can disable control components which we are not using (e.g. circle, marker, and polyline). For more information see the Leaflet.Draw documentation

Calling the Listing API

Now that we have our map, layers, and draw control setup we can finally start pulling listings from SimplyRETS. In order for the draw control to do this, we must implement an event listener callback function which describes what to do when shapes are created on the map using the draw control

Leaflet uses event methods to hook into the Map and run functions. The on function is used to add an event listener to an object (e.g. a Map). For example, map.on('click', function(e) { alert(e.latlng); }); could be used to run a function when a user clicks on the map.

We need to hook into our draw controls 'draw:created' event in order to properly handle draw events on our map.

Since our event listener will be run when a polygon is overlayed on the map, we can outline a set of steps to request data from the SimplyRETS api using the lat/lng coordinates drawn by the user.

1. Get latitude longitude coordinates from the Draw Control.
2. Request listings from the SimplyRETS API using the
latitude/longitude points as query parameters
3. Place each listing in the API response as a point on the map.

First, the callback extracts and formats the latitude/longitude points from the new polygon. The argument passed to function(e) { .. } is the event. Unsurprisingly, the event contains a layer for the new polygon. Calling getLatLngs() on the layer will return a list of latitude/longitude points.

The $.map function from jQuery is used to format the lat/lng points into a suitable format for the SimplyRETS points query parameter. The function passed to $.map returns a name/value pair for each point in the polygon and is stored in the latLng var.

An ajax request is then created to submit the latLng points to the SimplyRETS properties endpoint and retrieve listings. We pass in the latLngs variable as the ajax data parameter. This means the list of latitude/longitude points are translated into query parameters in the GET request.

In the beforeSend function, we setup authentication to the SimplyRETS api using test credentials. Using test credentials here is for test purposes only. Use caution when determining how to handle authenticating your credentials from your app.

The final bit that’s needed, is a function to run on a successful request with the retrieved listing data. The $.ajax function provides an option named success for a function to with the response data.

Since the data retrieved is in JSON format by default, we can loop directly over each listing in the results using jQuery $.each function.

For each listing, we create a marker location and corresponding marker. To tie it all together, we use map.addLayer to add the marker to the map.

Conclusion

Voila, you should now see markers within a polygon region on your map. You can try a live demo of the code here.

The end result of our code can now be used as a starting point in any application which requires map-based search. The code is quite small and can be easily customized:

The Data Dictionary was created by RESO to standardize data names within RETS Real Estate Data. SimplyRETS uses the Data Dictionary as the basis to normalize all of the data in our API to get the highest compatibility level between MLS data feeds.

A unique identifier for this record from the immediate source. This may be a number, or string that can include URI or other forms. This is the system you are connecting to and not necessarily the original source of the record.

The well known identifier for the listing. The value may be identical to that of the Listing Key, but the Listing ID is intended to be the value used by a human to retrieve the information about a specific listing. In a multiple originating system or a merged system, this value may not be unique and may require the use of the provider system to create a synthetic unique value.

Unique identifier from the originating system which is commonly a key to that system. In the case where data is passed through more than one system, this is the originating system key. This is a foreign key relating to the system where this record was originated.

Defines the type or level of service the listing member will be providing to the selling home owner. This will typically be a single selection. Examples include Full Service, Limited Service or Entry Only.

The status of the listing as it reflects the state of the contract between the listing agent and seller or an agreement with a buyer. (Active, Backup, Canceled, Closed, Expired, Pending, Withdrawn). Single Select

The effective date of the agreement between the seller and the seller’s broker. This is the date entered by the agent reflecting when the change occurred contractually, not a timestamp of when the change was made in the MLS.

The date when the listing agreement will expire. This is the date entered by the agent reflecting when the change occurred, or will occur, contractually, not a timestamp of when the change was made in the MLS. The expiration date of listings, prior to their expiration, cancellation, sale or lease, is confidential information and should be restricted to the agent and their managers, partners or broker.

Date the listing contract between the seller and listing agent was cancelled. This is the date entered by the agent reflecting when the change occurred contractually, not a timestamp of when the change was made in the MLS.

The date an offer was made with a contingency. The Listing remains On Market. This is the date entered by the agent reflecting when the change occurred contractually, not a timestamp of when the change was made in the MLS.

Date the listing was withdrawn from the market. This is not when a listing contact was cancelled or closed, but a withdrawal from the market while the contract between the seller and listing agent is still in effect and an offer has not been accepted. This is the date entered by the agent reflecting when the change occurred contractually, not a timestamp of when the change was made in the MLS.

With for-sale listings, the date an offer was accepted and the listing was no longer on market. This is the date entered by the agent reflecting when the change occurred contractually, not a timestamp of when the change was made in the MLS. With lease listings this may represent a meeting of the minds to lease, but some contractual requirements are yet to be fulfilled, such as contract signing or receipt of the deposit.

With for-sale listings, the date the purchase agreement was fulfilled. With lease listings, the date the requirements were fulfilled, such as contract and/or deposit. This is the date entered by the agent reflecting when the change occurred contractually, not a timestamp of when the change was made in the MLS.

The date the listing was placed on market. Where possible, this date is reflective of the date entered by the agent reflecting when the change occurred contractually, not a timestamp of when the change was made in the MLS.

The date the listing was taken off market. Where possible, this date is reflective of the date entered by the agent reflecting when the change occurred contractually, not a timestamp of when the change was made in the MLS.

Description of the last major change on the listing, i.e. “price reduction”, “back on market”, etc. May be used to display on a summary view of listing results to quickly identify listings that have had major changes recently.

The transactional timestamp automatically recorded by the MLS system representing the most recent date/time the listing’s status was set to Active or Backup. This also includes initial input of the listing to Active/Backup or from a draft or approval status to Active/Backup.

A commission rate is a dual commission rate, a variable commission rate, or both. A dual or variable rate commission arrangement is one in which the seller agrees to pay a specified commission if the property is sold by the listing broker without assistance and a different commission if the sale results through the efforts of a cooperating broker, or one in which the seller agrees to pay a specified commission if the property is sold by the listing broker either with or without the assistance of a cooperating broker and a different commission if the sale results through the efforts of a seller.

Text remarks that may be displayed to the public. In an MLS, it is the field where information is entered for the public. This information is intended to be visible on-line. This is typically information that describes the selling points of the building and/or land for sale. Local conditions and rules will determine what such content can contain. Generally, the following information is excluded: any information pertaining to entry to the property, the seller and/or tenant, listing member contact information. In other systems, these remarks will be determined by local business rules.

Becoming more common in the industry, MLS’s are hosting a separate “Public Remarks” for syndication purposes. This field should be defaulted to containing the Public Remarks, but upon broker decision, modified to include contact and other information denied by IDX rules, but allowed under local and national regulations.

Remarks that detail the seller’s instructions for showing the subject property. Showing instructions may include: contact information, showing times, notice required or other information. These remarks are privileged and are not for public viewing.

Terms of the listing such as Lien Release, Subject to Court Approval or Owner Will Carry. Also may include options that describe the financing terms that are acceptable to the seller, i.e. cash, assumable, FHA loan, etc.

The dollar amount of the concessions. If the concessions are made by the seller, some may subtract this value from the sales price as a means of calculating their own true price. If concessions are made by the buyer, some may add this amount to the sale price to create their own true price. Concessions made by both buyer and seller should be subtracted from each other providing a net value. Details of this calculation should be added to the Concessions Comments field.

The street number portion of a listed property’s street address. In some areas the street number may contain non-numeric characters. This field can also contain extensions and modifiers to the street number, such as “1/2” or “-B”. This street number field should not include Prefixes, Direction or Suffixes.

Text field containing the number or portion of a larger building or complex. Unit Number should appear following the street suffix or, if it exists, the street suffix direction, in the street address. Examples are: “APT G”, “55”, etc.

The group of addresses to which the USPS assigns the same code to aid in mail delivery. For the USPS, these codes are 9 digits: 5 numbers for the ZIP Code, one letter for the carrier route type, and 3 numbers for the carrier route number.

A map coordinate for the property, as determined by local custom. This is not necessarily the same as the geographic coordinate but may depend on the coordinate system used by whatever mapping service is customarily used by the listing service.

The name of the high school district having a catchment area that includes the associated property. When only one school district is used, this field should be used over the Junior or Elementary Districts.

North American 10 digit phone numbers should be in the format of ###-###-#### (separated by hyphens). Other conventions should use the common local standard. International numbers should be preceded by a plus symbol.

North American 10 digit phone numbers should be in the format of ###-###-#### (separated by hyphens). Other conventions should use the common local standard. International numbers should be preceded by a plus symbol.

North American 10 digit phone numbers should be in the format of ###-###-#### (separated by hyphens). Other conventions should use the common local standard. International numbers should be preceded by a plus symbol.

North American 10 digit phone numbers should be in the format of ###-###-#### (separated by hyphens). Other conventions should use the common local standard. International numbers should be preceded by a plus symbol.

North American 10 digit phone numbers should be in the format of ###-###-#### (separated by hyphens). Other conventions should use the common local standard. International numbers should be preceded by a plus symbol.

North American 10 digit phone numbers should be in the format of ###-###-#### (separated by hyphens). Other conventions should use the common local standard. International numbers should be preceded by a plus symbol.

North American 10 digit phone numbers should be in the format of ###-###-#### (separated by hyphens). Other conventions should use the common local standard. International numbers should be preceded by a plus symbol.

North American 10 digit phone numbers should be in the format of ###-###-#### (separated by hyphens). Other conventions should use the common local standard. International numbers should be preceded by a plus symbol.

North American 10 digit phone numbers should be in the format of ###-###-#### (separated by hyphens). Other conventions should use the common local standard. International numbers should be preceded by a plus symbol.

A system unique identifier. Specifically, in aggregation systems, the ListAgentKey is the system unique identifier from the system that the record was retrieved. This may be identical to the related xxxId. This is a foreign key relating to the Member resource’s MemberKey.

North American 10 digit phone numbers should be in the format of ###-###-#### (separated by hyphens). Other conventions should use the common local standard. International numbers should be preceded by a plus symbol.

North American 10 digit phone numbers should be in the format of ###-###-#### (separated by hyphens). Other conventions should use the common local standard. International numbers should be preceded by a plus symbol.

A system unique identifier. Specifically, in aggregation systems, the Key is the system unique identifier from the system that the record was just retrieved. This may be identical to the related xxxId identifier, but the key is guaranteed unique for this record set. This is a foreign key relating to the Office resource’s OfficeKey.

North American 10 digit phone numbers should be in the format of ###-###-#### (separated by hyphens). Other conventions should use the common local standard. International numbers should be preceded by a plus symbol.

North American 10 digit phone numbers should be in the format of ###-###-#### (separated by hyphens). Other conventions should use the common local standard. International numbers should be preceded by a plus symbol.

North American 10 digit phone numbers should be in the format of ###-###-#### (separated by hyphens). Other conventions should use the common local standard. International numbers should be preceded by a plus symbol.

North American 10 digit phone numbers should be in the format of ###-###-#### (separated by hyphens). Other conventions should use the common local standard. International numbers should be preceded by a plus symbol.

North American 10 digit phone numbers should be in the format of ###-###-#### (separated by hyphens). Other conventions should use the common local standard. International numbers should be preceded by a plus symbol.

North American 10 digit phone numbers should be in the format of ###-###-#### (separated by hyphens). Other conventions should use the common local standard. International numbers should be preceded by a plus symbol.

North American 10 digit phone numbers should be in the format of ###-###-#### (separated by hyphens). Other conventions should use the common local standard. International numbers should be preceded by a plus symbol.

North American 10 digit phone numbers should be in the format of ###-###-#### (separated by hyphens). Other conventions should use the common local standard. International numbers should be preceded by a plus symbol.

North American 10 digit phone numbers should be in the format of ###-###-#### (separated by hyphens). Other conventions should use the common local standard. International numbers should be preceded by a plus symbol.

A system unique identifier. Specifically, in aggregation systems, the Key is the system unique identifier from the system that the record was just retrieved. This may be identical to the related xxxId identifier, but the key is guaranteed unique for this record set. This is a foreign key relating to the Member resource’s MemberKey.

North American 10 digit phone numbers should be in the format of ###-###-#### (separated by hyphens). Other conventions should use the common local standard. International numbers should be preceded by a plus symbol.

North American 10 digit phone numbers should be in the format of ###-###-#### (separated by hyphens). Other conventions should use the common local standard. International numbers should be preceded by a plus symbol.

A system unique identifier. Specifically, in aggregation systems, the Key is the system unique identifier from the system that the record was just retrieved. This may be identical to the related xxxId identifier, but the key is guaranteed unique for this record set. This is a foreign key relating to the Office resource’s OfficeKey.

North American 10 digit phone numbers should be in the format of ###-###-#### (separated by hyphens). Other conventions should use the common local standard. International numbers should be preceded by a plus symbol.

North American 10 digit phone numbers should be in the format of ###-###-#### (separated by hyphens). Other conventions should use the common local standard. International numbers should be preceded by a plus symbol.

North American 10 digit phone numbers should be in the format of ###-###-#### (separated by hyphens). Other conventions should use the common local standard. International numbers should be preceded by a plus symbol.

North American 10 digit phone numbers should be in the format of ###-###-#### (separated by hyphens). Other conventions should use the common local standard. International numbers should be preceded by a plus symbol.

North American 10 digit phone numbers should be in the format of ###-###-#### (separated by hyphens). Other conventions should use the common local standard. International numbers should be preceded by a plus symbol.

North American 10 digit phone numbers should be in the format of ###-###-#### (separated by hyphens). Other conventions should use the common local standard. International numbers should be preceded by a plus symbol.

North American 10 digit phone numbers should be in the format of ###-###-#### (separated by hyphens). Other conventions should use the common local standard. International numbers should be preceded by a plus symbol.

North American 10 digit phone numbers should be in the format of ###-###-#### (separated by hyphens). Other conventions should use the common local standard. International numbers should be preceded by a plus symbol.

North American 10 digit phone numbers should be in the format of ###-###-#### (separated by hyphens). Other conventions should use the common local standard. International numbers should be preceded by a plus symbol.

A system unique identifier. Specifically, in aggregation systems, the Key is the system unique identifier from the system that the record was just retrieved. This may be identical to the related xxxId identifier, but the key is guaranteed unique for this record set. This is a foreign key relating to the Member resource’s MemberKey.

North American 10 digit phone numbers should be in the format of ###-###-#### (separated by hyphens). Other conventions should use the common local standard. International numbers should be preceded by a plus symbol.

North American 10 digit phone numbers should be in the format of ###-###-#### (separated by hyphens). Other conventions should use the common local standard. International numbers should be preceded by a plus symbol.

A system unique identifier. Specifically, in aggregation systems, the Key is the system unique identifier from the system that the record was just retrieved. This may be identical to the related xxxId identifier, but the key is guaranteed unique for this record set. This is a foreign key relating to the Office resource’s OfficeKey.

North American 10 digit phone numbers should be in the format of ###-###-#### (separated by hyphens). Other conventions should use the common local standard. International numbers should be preceded by a plus symbol.

North American 10 digit phone numbers should be in the format of ###-###-#### (separated by hyphens). Other conventions should use the common local standard. International numbers should be preceded by a plus symbol.

North American 10 digit phone numbers should be in the format of ###-###-#### (separated by hyphens). Other conventions should use the common local standard. International numbers should be preceded by a plus symbol.

North American 10 digit phone numbers should be in the format of ###-###-#### (separated by hyphens). Other conventions should use the common local standard. International numbers should be preceded by a plus symbol.

North American 10 digit phone numbers should be in the format of ###-###-#### (separated by hyphens). Other conventions should use the common local standard. International numbers should be preceded by a plus symbol.

North American 10 digit phone numbers should be in the format of ###-###-#### (separated by hyphens). Other conventions should use the common local standard. International numbers should be preceded by a plus symbol.

North American 10 digit phone numbers should be in the format of ###-###-#### (separated by hyphens). Other conventions should use the common local standard. International numbers should be preceded by a plus symbol.

North American 10 digit phone numbers should be in the format of ###-###-#### (separated by hyphens). Other conventions should use the common local standard. International numbers should be preceded by a plus symbol.

North American 10 digit phone numbers should be in the format of ###-###-#### (separated by hyphens). Other conventions should use the common local standard. International numbers should be preceded by a plus symbol.

A system unique identifier. Specifically, in aggregation systems, the Key is the system unique identifier from the system that the record was just retrieved. This may be identical to the related xxxId identifier, but the key is guaranteed unique for this record set. This is a foreign key relating to the Member resource’s MemberKey.

North American 10 digit phone numbers should be in the format of ###-###-#### (separated by hyphens). Other conventions should use the common local standard. International numbers should be preceded by a plus symbol.

North American 10 digit phone numbers should be in the format of ###-###-#### (separated by hyphens). Other conventions should use the common local standard. International numbers should be preceded by a plus symbol.

A system unique identifier. Specifically, in aggregation systems, the Key is the system unique identifier from the system that the record was just retrieved. This may be identical to the related xxxId identifier, but the key is guaranteed unique for this record set. This is a foreign key relating to the Office resource’s OfficeKey.

A system unique identifier. Specifically, in aggregation systems, the Key is the system unique identifier from the system that the record was just retrieved. This may be identical to the related xxxId identifier, but the key is guaranteed unique for this record set. This is a foreign key relating to the Teams resource’s TeamKey.

A system unique identifier. Specifically, in aggregation systems, the Key is the system unique identifier from the system that the record was just retrieved. This may be identical to the related xxxId identifier, but the key is guaranteed unique for this record set. This is a foreign key relating to the Teams resource’s TeamKey.

The phone number of the Home Owners Association. North American 10 digit phone numbers should be in the format of ###-###-#### (separated by hyphens). Other conventions should use the common local standard. International numbers should be preceded by a plus symbol.

The phone number of the second of two Home Owners Association. North American 10 digit phone numbers should be in the format of ###-###-#### (separated by hyphens). Other conventions should use the common local standard. International numbers should be preceded by a plus symbol.

The dimensions of the lot minimally represented as length and width (i.e. 250 x 180) or a measurement of all sides of the polygon representing the property lines of the property. i.e. 30 x 50 x 120 x 60 x 22.

The total Acres of the lot. This field is related to the Lot Size Area and Lot Size Units and must be in sync with the values represented in those fields. Lot Size Source also applies to this field when used.

The total square footage of the lot. This field is related to the Lot Size Area and Lot Size Units and must be in sync with the values represented in those fields. Lot Size Source also applies to this field when used.

Pick list of types of Road frontage. i.e. Freeway frontage, No Road Frontage, etc. The road frontage of the property is an important factor in determining value of the property and it’s appropriateness for intended use.

Pick list of types of surface of the Road to access the property. The surface of the road(s) for access to the property is an important factor in determining value of the property and it’s appropriateness for intended use.

North American 10 digit phone numbers should be in the format of ###-###-#### (separated by hyphens). Other conventions should use the common local standard. International numbers should be preceded by a plus symbol.

North American 10 digit phone numbers should be in the format of ###-###-#### (separated by hyphens). Other conventions should use the common local standard. International numbers should be preceded by a plus symbol.

A list of the type(s) of current use of the property. The current use of the property is an important factor in understanding the overall condition of the land and determining it’s appropriateness for intended use.

A list of the type(s) of possible or best uses of the property. Probable use gives a good indication of what the best use or potential use of the property could be. i.e. Primary, Vacation, Investment, Rental, Retirement

Total number of lots on the property or included in the sale. Land properties are often sold with multiple lots. It is important to be able to describe how many lots are in the property and not in all cases do lots have separate Parcel IDs.

Net operating income is the revenue from a property after operating expenses have been deducted, but before deducting income taxes and financing expenses (interest and Principal Payments). For example, Gross Income - Operating Expenses = Net Operating Income (NOI).

Cap Rate is equivalent to the return on investment you would receive if you pay cash for a property. The ratio between the net operating income produced by an asset and its capital cost (the original price paid to buy the asset) or alternatively its current market value.

The annual expense that is not paid directly by the tenant and is included in the Operating Expense calculations. This is for an individual manager. Use ProfessionalManagementExpense for a management company.

A simplified enumerated list of the days and hours of operation of the business being sold. i.e. Open 24 Hours or Open 7 Days. For more detailed descriptions use the HoursDaysofOperationDescription field.

The source of the measurements. This may be a pick list of options showing the source of the measurement. i.e. Agent, Assessor, Estimate, etc. This field applies to all farm area fields (Cultivated, Pasture, Range, Wooded)

The simple sum of the number of bathrooms. For example for a property with two Full Bathrooms and one Half Bathroom, the Bathrooms Total Integer will be 3. To express this example as 2.5, use the BathroomsTotalDecimal field. To express this example as 2.1, use the BathroomsTotalNotational.

A room containing all 4 of the 4 elements constituting a bath, which are; Toilet, Sink, Bathtub or Shower Head. A Full Bath will typically contain four elements; Sink, Toilet, Tub and Shower Head (in tub or stall). However, some may considered a Sink, Toilet and Tub (without a shower) a Full Bath, others consider this to be a Three Quarter Bath. In the event that BathroomsThreeQuarter is not in use, this field may represent the sum of all Full and Three Quarter bathrooms.

A room containing 3 of the 4 elements constituting a bath, which are; Toilet, Sink, Bathtub or Shower Head. A typical Three Quarter Bath will contain Sink, Toilet and Shower. Some may considered a Sink, Toilet and Tub (without a shower) a Three Quarter Bath, others consider this to be a Full Bath.

The number of partial bathrooms in the property being sold/leased. When used in combination with the BathroomsFull field, this replaces (or is the sum of) all Half and One Quarter bathrooms; and in the event BathroomsThreeQuarter is not used, BathroomsFull replaces (or is the sum of) all Full and Three Quarter baths. This field should not be used in combination with the BathroomsOneQuarter or the BathroomsHalf.

A flag indicating that the primary structure is attached to another structure that is not included in the sale. i.e. one unit of a duplex. This flag may be T/F, Y/N or a list of attached or detached. As with all flags, the field may be null. In some systems this information may be part of the Property Sub Type.

The number of levels in the property being sold. For example, One Level, Two Levels, Split Level, Three or More Levels, Multi Level, Loft. A discreet horizontal plane of interior living space (excluding basements).

The year that an occupancy permit is first granted for the house or other local measure of initial habitability of the build. The type definition permits an empty value with an attribute noting that it is an unknown date or that the building is new construction. While constraints have not been applied, convention at the time of adoption has this as a four (4) digit year value.

A number used to uniquely identify a parcel or lot. This number is typically issued by the county or county assessor. The AP number format varies from county to county. It is recommended that all Parcel Numbers be transmitted without dashes or hyphens.

A multi select list with options like 1 Common Wall, 2 Common Walls, No Common Walls, No One Above, No One Below. Implementation should include rules preventing illogical selection combinations and to ensure consistency with the Property Attached Y/N field.

The dimensions of the RV parking area minimally represented as length and width (i.e. 25 x 18) or a measurement of all sides of the polygon representing the usable RV parking space. i.e. 33 x 15 x 12 x 60.

A numeric field that describes the level within the structure, SFR or a unit in a building, where the main entry to the dwelling is located. When a unit has one floor it is implicit that this is also the level of the unit itself.

The name of the verification or certification awarded to a new or pre-existing residential or commercial structure. For example: LEED, Energy Star, ICC-700. In cases where more than one certification have been awarded, leverage multiple iterations of the green verification fields via the repeating element method.

The name of the body or group providing the verification or certification named in the GreenBuildingVerificationType field. This is often the same name but some certifications/verifications can be issued from difference bodies. This is a repeating element. If desired replace [Type] with the name of the certification from the GreenBuildingVerificationType list.

Many verifications or certifications have a rating system that provides an indication of the structure’s level of energy efficiency. When expressed in a numeric value, please use the GreenVerificationMetric field. Verifications and Certifications can also be a name, such as Gold or Silver, which is the purpose of this field. This is a repeating element. If desired replace [Type] with the name of the certification from the GreenBuildingVerificationType list.

A final score indicating the performance of energy efficiency design and measures in the home as tested by a third-party rater. Points achieved to earn a certification in the HighPerformanceRating field do not apply to this field. HERS Index is most common with new homes and runs with a lower number being more efficient. A net-zero home uses zero energy and has a HERS score of 0. A home that produces more energy than it uses has a negative score. Home Energy Score is a tool more common for existing homes and runs with a higher number being more efficient. It takes square footage into account and caps with 10 as the highest number of points. This is a repeating element. If desired replace [Type] with the name of the certification from the GreenBuildingVerificationType list.

Provides a link to the specific property’s high-performance rating or scoring details directly from and hosted by the sponsoring body of the program. Typically provides thorough details, for example, which points where achieved and how, or in the case of a score what specifically was tested and the results. This is a repeating element. If desired replace [Type] with the name of the certification from the GreenBuildingVerificationType list.

Add this pick list of features and locations where the laundry is located in the property being sold. i.e. Gas Dryer Hookup, In Kitchen, In Garage, etc. CRMLS sees over 50% utilization of this field which has a dozen enumerations making it too long to fold into other fields such as rooms or Interior Features.

A walkability index based on the time to walk from a property to near by essentials such as grocery stores, schools, churches, etc. See www.walkscore.com for more information and requirements for using WalkScore.

North American 10 digit phone numbers should be in the format of ###-###-#### (separated by hyphens). Other conventions should use the common local standard. International numbers should be preceded by a plus symbol.

This field is a list of the types used in the rooms repeating elements. The Type is a list of possible room types. i.e. Bedroom, Bathroom, Living Room, Workshop, etc. Each selected are expected to appear as the “[type]” in the related rooms fields in a flattened implementation (RETS 1.x only) of the room fields. A relational implementation of rooms must omit the type from the field name and use RoomType to create a vertical representation of the various rooms. **Note that Garage or Basement should not be added as a room type and are represented by the ParkingFeatures and Basement fields respectively.

[type] This field is a repeating element for each type of room selected in the RoomType field. For every RoomType there are two possible implementations. For a flat implementation (RETS 1.x only), each RoomType used is expected to appear as the “[type]” in the related rooms field name. i.e. RoomKitchenArea. A relational implementation of rooms must omit the type from the field name and use RoomType to create a vertical representation of the various rooms. i.e. RoomArea with Kitchen in the relational table’s RoomType field.

[type] This field is a repeating element for each type of room selected in the RoomType field. For every RoomType there are two possible implementations. For a flat implementation (RETS 1.x only), each RoomType used is expected to appear as the “[type]” in the related rooms field name. i.e. RoomKitchenAreaUnits. A relational implementation of rooms must omit the type from the field name and use RoomType to create a vertical representation of the various rooms. i.e. RoomAreaUnits with Kitchen in the relational table’s RoomType field.

[type] This field is a repeating element for each type of room selected in the RoomType field. For every RoomType there are two possible implementations. For a flat implementation (RETS 1.x only), each RoomType used is expected to appear as the “[type]” in the related rooms field name. i.e. RoomKitchenAreaSource. A relational implementation of rooms must omit the type from the field name and use RoomType to create a vertical representation of the various rooms. i.e. RoomAreaSource.

[type] This field is a repeating element for each type of room selected in the RoomType field. For every RoomType there are two possible implementations. For a flat implementation (RETS 1.x only), each RoomType used is expected to appear as the “[type]” in the related rooms field name. i.e. RoomKitchenDimensions. A relational implementation of rooms must omit the type from the field name and use RoomType to create a vertical representation of the various rooms. i.e. RoomDimensions with Kitchen in the relational table’s RoomType field.

[type] This field is a repeating element for each type of room selected in the RoomType field. For every RoomType there are two possible implementations. For a flat implementation (RETS 1.x only), each RoomType used is expected to appear as the “[type]” in the related rooms field name. i.e. RoomKitchenLength. A relational implementation of rooms must omit the type from the field name and use RoomType to create a vertical representation of the various rooms. i.e. RoomLength with Kitchen in the relational table’s RoomType field.

[type] This field is a repeating element for each type of room selected in the RoomType field. For every RoomType there are two possible implementations. For a flat implementation (RETS 1.x only), each RoomType used is expected to appear as the “[type]” in the related rooms field name. i.e. RoomKitchenWidth. A relational implementation of rooms must omit the type from the field name and use RoomType to create a vertical representation of the various rooms. i.e. RoomWidth with Kitchen in the relational table’s RoomType field.

[type] This field is a repeating element for each type of room selected in the RoomType field. For every RoomType there are two possible implementations. For a flat implementation (RETS 1.x only), each RoomType used is expected to appear as the “[type]” in the related rooms field name. i.e. RoomKitchenWidthUnits. A relational implementation of rooms must omit the type from the field name and use RoomType to create a vertical representation of the various rooms. i.e. RoomWidthUnits with Kitchen in the relational table’s RoomType field.

[type] This field is a repeating element for each type of room selected in the RoomType field. For every RoomType there are two possible implementations. For a flat implementation (RETS 1.x only), each RoomType used is expected to appear as the “[type]” in the related rooms field name. i.e. RoomKitchenWidthSource. A relational implementation of rooms must omit the type from the field name and use RoomType to create a vertical representation of the various rooms. i.e. RoomWidthSource with Kitchen in the relational table’s RoomType field.

[type] This field is a repeating element for each type of room selected in the RoomType field. For every RoomType there are two possible implementations. For a flat implementation (RETS 1.x only), each RoomType used is expected to appear as the “[type]” in the related rooms field name. i.e. RoomKitchenLevel. A relational implementation of rooms must omit the type from the field name and use RoomType to create a vertical representation of the various rooms. i.e. RoomLevel with Kitchen in the relational table’s RoomType field.

[type] This field is a repeating element for each type of room selected in the RoomType field. For every RoomType there are two possible implementations. For a flat implementation (RETS 1.x only), each RoomType used is expected to appear as the “[type]” in the related rooms field name. i.e. RoomKitchenFeatures. A relational implementation of rooms must omit the type from the field name and use RoomType to create a vertical representation of the various rooms. i.e. RoomFeatures with Kitchen in the relational table’s RoomType field.

[type] This field is a repeating element for each type of room selected in the RoomType field. For every RoomType there are two possible implementations. For a flat implementation (RETS 1.x only), each RoomType used is expected to appear as the “[type]” in the related rooms field name. i.e. RoomKitchenDescription. A relational implementation of rooms must omit the type from the field name and use RoomType to create a vertical representation of the various rooms. i.e. RoomDescription with Kitchen in the relational table’s RoomType field.

This field is a list of the types used in the Unit Type repeating elements. The Type is a list of possible Unit Types. i.e. 1, 2, 3 or 2 Bed, Studio, Special Loft, etc. Each selected are expected to appear as the “[type]” in the related UnitType fields in a flattened implementation (RETS 1.x only) of the room fields. A relational implementation of UnitTypes must omit the type from the field name and use UnitTypeType to create a vertical representation of the various unit types. The fact that the field repeats the word “type” is intentional.

[type] This field is a repeating element for each type of unit selected in the UnitType field. For every UnitType there are two possible implementations. For a flat implementation (RETS 1.x only), each UnitTypeType used is expected to appear as the “[type]” in the related rooms field name. i.e. UnitTypeStudioUnitsTotal. A relational implementation of UnitType must omit the type from the field name and use UnitTypeType to create a vertical representation of the various rooms. i.e. UnitTypeUnitsTotal with Studio in the relational table’s UnitType field.

[type] This field is a repeating element for each type of unit selected in the UnitType field. For every UnitType there are two possible implementations. For a flat implementation (RETS 1.x only), each UnitTypeType used is expected to appear as the “[type]” in the related rooms field name. i.e. UnitTypeStudioBedsTotal. A relational implementation of UnitType must omit the type from the field name and use UnitTypeType to create a vertical representation of the various rooms. i.e. UnitTypeBedsTotal with Studio in the relational table’s UnitType field.

[type] This field is a repeating element for each type of unit selected in the UnitType field. For every UnitType there are two possible implementations. For a flat implementation (RETS 1.x only), each UnitTypeType used is expected to appear as the “[type]” in the related rooms field name. i.e. UnitTypeStudioBathsTotal. A relational implementation of UnitType must omit the type from the field name and use UnitTypeType to create a vertical representation of the various rooms. i.e. UnitTypeBathsTotal with Studio in the relational table’s UnitType field.

[type] This field is a repeating element for each type of unit selected in the UnitType field. For every UnitType there are two possible implementations. For a flat implementation (RETS 1.x only), each UnitTypeType used is expected to appear as the “[type]” in the related rooms field name. i.e. UnitTypeStudioFurnished. A relational implementation of UnitType must omit the type from the field name and use UnitTypeType to create a vertical representation of the various rooms. i.e. UnitTypeFurnished with Studio in the relational table’s UnitType field.

[type] This field is a repeating element for each type of unit selected in the UnitType field. For every UnitType there are two possible implementations. For a flat implementation (RETS 1.x only), each UnitTypeType used is expected to appear as the “[type]” in the related rooms field name. i.e. UnitTypeStudioDescription. A relational implementation of UnitType must omit the type from the field name and use UnitTypeType to create a vertical representation of the various rooms. i.e. UnitTypeDescription with Studio in the relational table’s UnitType field.

[type] This field is a repeating element for each type of unit selected in the UnitType field. For every UnitType there are two possible implementations. For a flat implementation (RETS 1.x only), each UnitTypeType used is expected to appear as the “[type]” in the related rooms field name. i.e. UnitTypeStudioGarageSpaces. A relational implementation of UnitType must omit the type from the field name and use UnitTypeType to create a vertical representation of the various rooms. i.e. UnitTypeGarageSpaces with Studio in the relational table’s UnitType field.

[type] This field is a repeating element for each type of unit selected in the UnitType field. For every UnitType there are two possible implementations. For a flat implementation (RETS 1.x only), each UnitTypeType used is expected to appear as the “[type]” in the related rooms field name. i.e. UnitTypeStudioGarageAttachedYN. A relational implementation of UnitType must omit the type from the field name and use UnitTypeType to create a vertical representation of the various rooms. i.e. UnitTypeGarageAttachedYN with Studio in the relational table’s UnitType field.

[type] This field is a repeating element for each type of unit selected in the UnitType field. For every UnitType there are two possible implementations. For a flat implementation (RETS 1.x only), each UnitTypeType used is expected to appear as the “[type]” in the related rooms field name. i.e. UnitTypeStudioActualRent. A relational implementation of UnitType must omit the type from the field name and use UnitTypeType to create a vertical representation of the various rooms. i.e. UnitTypeActualRent with Studio in the relational table’s UnitType field.

[type] This field is a repeating element for each type of unit selected in the UnitType field. For every UnitType there are two possible implementations. For a flat implementation (RETS 1.x only), each UnitTypeType used is expected to appear as the “[type]” in the related rooms field name. i.e. UnitTypeStudioTotalRent. A relational implementation of UnitType must omit the type from the field name and use UnitTypeType to create a vertical representation of the various rooms. i.e. UnitTypeTotalRent with Studio in the relational table’s UnitType field.

[type] This field is a repeating element for each type of unit selected in the UnitType field. For every UnitType there are two possible implementations. For a flat implementation (RETS 1.x only), each UnitTypeType used is expected to appear as the “[type]” in the related rooms field name. i.e. UnitTypeStudioProForma. A relational implementation of UnitType must omit the type from the field name and use UnitTypeType to create a vertical representation of the various rooms. i.e. UnitTypeProForma with Studio in the relational table’s UnitType field.

A division of the city or county into areas of different permissible land uses. This Zone field should be used for the short code that is commonly used. For full textual descriptions please use the ZoningDescription field.

A list of descriptions of the zoning of the property. The zoning codes are often non-descriptive and variant. Zoning Description is a more descriptive form of the zoning for the property, i.e. Agricultural, Residential, Rezone Possible, etc. Specific zone codes must be added to the Zoning field.

A type of legal description for land in developed areas where streets or other rights-of-ways delineate large parcels of land referred to as divided into lots on which homes or other types of developments are built. An example would read “Lot 12 of Block 45 of Tract 3002 of the City of San Dunes, Desert County.” Such a description would also reference an official plat filed with the clerk or recorder for that area which shows the location of the block and often the dimensions of the lots therein.

A type of legal description for land in developed areas where streets or other rights-of-ways delineate large parcels of land referred to as divided into lots on which homes or other types of developments are built. An example would read “Lot 12 of Block 45 of Tract 3002 of the City of San Dunes, Desert County.” Such a description would also reference an official plat filed with the clerk or recorder for that area which shows the location of the block and often the dimensions of the lots therein.

A type of legal description for land in developed areas where streets or other rights-of-ways delineate large parcels of land referred to as divided into lots on which homes or other types of developments are built. An example would read “Lot 12 of Block 45 of Tract 3002 of the City of San Dunes, Desert County.” Such a description would also reference an official plat filed with the clerk or recorder for that area which shows the location of the block and often the dimensions of the lots therein.

A type of legal description for land in developed areas where streets or other rights-of-ways delineate large parcels of land referred to as divided into lots on which homes or other types of developments are built. An example would read “Lot 12 of Block 45 of Tract 3002 of the City of San Dunes, Desert County.” Such a description would also reference an official plat filed with the clerk or recorder for that area which shows the location of the block and often the dimensions of the lots therein. The text here is also an index into the property as described by the County Recorder.

When you’re ready to build a new website with SimplyRETS, we try to make the process as simple as possible. There are a few things you’ll need to know about how it works, but we break it down into three easy steps to make everything as simple as possible:

Step 1: Activate a RETS feed with your MLS

This is necessary before creating an app.

To set up a SimplyRETS App, you will need a RETS feed set up at one or more MLS’s. Getting that set up usually only takes a day or two, if you don’t already have it. Contact your MLS for specific instructions on how to get set up with a RETS/IDX feed. They can guide you through the process.

Each MLS has different requirements about setting up a RETS feed, and how to use the RETS feed - please contact them for for specific inquiries. Our faq answers more questions on this.

Once you have RETS Credentials, you’re good to go! That’s the only prerequisite for setting up an app with SimplyRETS. Your MLS, or Association of Realtors, will send you a few things:

RETS Login URL

RETS Username

RETS Password

You will need these pieces of information when creating an app at Step 2.

If you already have RETS Credentials, even better! Just put them in the form when you’re creating your app and the rest is taken care of.

OK, we’ve got step one down! On to number two..

Step 2: Create an App

The second step is to create your app. This gives us all the information we need to get you set up with live listings in the API or WordPress plugin.

Payment information. We will charge your card only when your new app is ready to go and has passed our Quality Assurance Test.

Step 3: Start developing your website or application

Here come’s the fun part. We have everything we need and you’re ready to start developing the best real estate website out there!

When previous step is complete, we’ll start replicating your listings, replicating the photos for those listings, setting up your database, and generating the keys to your new feed! That usually takes about 48 hours.

When the SimplyRETS app is ready, you’ll get an email and you can log in to your account to get your new API credentials…that’s it!

When building real estate websites and applications with the SimplyRETS API, our built in pagination will allow you to easily create “pages” of listings. There are a couple different methods for creating pagination links - below is a short tutorial on how that can be accomplished.

I’ll use the command line application cURL for the following examples, which you can run from Windows, Mac, and Linux. Depending on what language you’re using for your application, the examples should translate pretty nicely to any built in HTTP library.

The limit parameter

By default, our API payload will return 20 listings and at a maximum 50. You can set how many listings to return with the limit parameter. For example, the following query will return 40 unfiltered listings:

Note that unfiltered simply means no additional parameters like maxprice

Our pagination is built using this parameter in addition to the offset parameter to traverse listings without showing duplicates on the client side.

Links in the HTTP headers

In the HTTP response header, we store a pre-created link to the next page of listings. The link includes any additional parameters from your original query, so you don’t have to worry about adding them back in.

The last line “Link” is what we’re looking for. The link returned is the API request you can make to get the next set of listings. If you’re already on the second or third page, it will also return a “previous” link to get back to the previous set of listings:

Link: ; rel="next",
; rel="prev"

Naturally, the rel="next" link will get the next set of listings, and the rel="prev" link will get the previous set.

Building your own pagination

It’s also possible to build the pagination links yourself, and sometimes that might be easier. Using the offset and limit parameter, it’s pretty easy to calculate those on the client side.

For a basic example, if your first query is all listings above $500,000 with a limit of 25 per page:

Today, I’m excited to announce the v1.3.4 release of our Wordpress plugin which has all new integration with Google Maps to give your visitors a better Real Estate property search experience.

SimplyRETS believes in making IDX and RETS searches better and easier to user. We’re constantly looking for ways to improve both our Wordpress Plugin and our API in this regard.

Features

The update comes with a suite of new features and options that are still just as simple to use:

Multiple map position options to give you control over what the user sees

Views for both search results and single listings

Info Windows with detailed listing overviews

The ability to turn map views on and off on a page by page basis

…and as always, free support for our SimplyRETS Tech Support team.

Getting Set Up

If you already have the plugin installed, getting the new map features is as easy as upgrading the plugin through your Wordpress dashboard.

If you don’t, now is as good a time as ever to get started. You can install the plugin from the Wordpress directory. We offer free demo listings so you can test out the new features without needing and account. When you’re ready to get your listings on your site, you can create an account and get live listings ony you site today!

Creating a map page

By default, the map view will show on all search pages along with the list view. This makes it easy for your visitors to choose listings from an area on the map, or from the list view overview. The quickest way to get started is to create a new SimplyRETS Post (SimplyRETS -> New SimplyRETS Page), give it a title, and publish!

Customizing the Map Position

If you would rather show the map view below the list view, or only show the map view, that’s a simple setting. In your dashboard, navigate to the SimplyRETS settings page (Settings -> SimplyRETS). Under the Map Settings section, you’ll have a few options:

Only Show List View

Only Show Map View

Show Map View Above List View

Show Map View Below List View

Pick the setting you think will be best for your visitors, and hit save. This setting will affect all search pages (any page with multiple listings on it).

Disabling the Map View in Specific Places

If there is area your site where you would rather not show the map view, you can easily disable it in specific places. When you use the shortcodes to insert listings in posts or pages, it may not be ideal to have a map take up a lot of space. To do this, simply add the show_map parameter to your shortcode and set it to false. Example:

[sr_residential show_map="false"]

Single Listing Map Views

Single listing map views are endabled by default, and will show on details pages about specific properties. At the top of each page, there is a ‘View on Map’ link (right next to our lead capture link!), that will take them to the map - which lies on the same page. There’s no difficulut configuration here - just a simple way for your visitors to get the best possible information about the property they’re viewing.

What’s next?

We’re constantly working on new features and brainstorming new ideas about how we can make a better IDX and RETS search. If you have a great idea that would be beneificial to you as an agent or developer, send us a message and let’s talk about making a better RETS API and Wordpress plugin! We’d love to hear what you need or what we can do to help your next big project become a success.

At SimplyRETS, we’ve been working diligently on giving brokerages and developers an easier way to build apps and websites using Real Estate listing data. We’re excited to announce that over the last 4 weeks, we’ve added fast track support for 8 new Real Estate Associations:

Houston Association of Realtors (HAR)

My Florida Regional MLS (MFR MLS)

Calgary Real Estate Board (CREB)

Kitchengton-Waterloo Association of Realtors (KWAR)

Massachusetts MLS Property Info Network (MLSPIN)

Southeast Florida MLS (SEF MLS)

Greater Las Vegas Association of Realtors (GLVAR)

Santa Cruz County Board of Realtors (SCCBAR)

What does that mean for developers?

Getting a RETS data feed from your Real Estate Association can be a tough and drawn out process. And once you do have it, the software developers now have to work for months to learn the RETS Standard, write code to replicate and store the listings in a database, and then develop an API to access those listings — all while maintaining compliance with MLS rules. The sheer time and money that it takes to do this deters a lot of Agents from building their ideas. Thus, perpetuating the lack of new technology in Real Estate.

SimplyRETS solves this by taking care of all of those things for you. We provide a hosted solution to replicate your listings, store them in a database, and expose an API for developers to work against – while still following the Associations rules and keeping the listings up to date. This means that applications can now be built faster, cheaper, and better. And developers don’t need a deep knowledge of the Real Estate Transaction Standard to build amazing applications using the SimplyRETS platform.

Fast Track Support

Normally our systems takes about 48–72 hours to get everything set up for a new account. Recently, we’ve been working on making that even faster. If your association is a part of our Fast Track Support List, setting up your RETS feed now just takes a couple of hours. This means you can get started building your website or application today, not in two weeks when the idea is not so fresh.

How Can My Association Get Fast Tracked?

If you build Real Estate websites or applications, you can help us to get more Associations added! Just reach out to us and we’ll work with you to get set up.

Welcome to the SimplyRETS Blog! SimplyRETS is a service which connects to your RETS/IDX feed to offer a vastly simplified and modern REST API. We are helping developers building real estate software save time and money so they can focus on what’s importand; innovation. SimplyRETS makes it easy for developers with little or no experience in real estate data to get started quickly.

Our Goals

Offer a simplified, modern, and familiar API (Application Programming Interface) to developers which will help them iterate quickly on real estate software.

Allow agents unbranded access to their data. We don’t require our feeds to carry any SimplyRETS branding. Of course, your data is still subject to MLS rules. However, SimplyRETS wants to enhance and promote business applications built around lead generation.

Help developers and agents save time by not worrying about MLS compliance issues. We prioritize accurate and up-to-date data feeds. We also work with developers to make sure their application or website remains compliant with little to no maintenance or upkeep.

Build on a strong core data service, influenced by the RESO Data Dictionary. This core data model makes it possible for apps to interface with multiple MLS vendors out-of-the-box. This workflow is baked directly into our API and does not carry any extra recurring charges.

Distribute more free and open material for developers and agents to learn about their real estate data and how it works. All the code on our Github is free and open-source. We will also be working on tutorials, examples, and how-to’s to promote more innovative real estate development.

The REST API (Not to be confused with RETS)

Our REST API is the core of our service. You can see how it works by checking out our documentation. A simple example, using our trial data, would be to use curl:

Why do I need this?

We often work with developers who are completely capable of working with the raw RETS data themselves. Up front, they often ask why they need such a service. We generally respond with:

Lower Maintenance and Upkeep

We can significantly lower the maintenance and upkeep time for developers. The cost of using our service usually pales in comparison to a developer spending even a few hours a month maintaining a feed.

Hosted

The cost of maintening a replicated RETS database is often simply too high to be practical. Developers working with RETS feeds often can’t control some of the long-term factors which degrade their service and it deters them from picking up new projects period.

Thats where SimplyRETS comes in. We take care of these issues. We host the database and backend integration systems.

We are serious about maintaining an extremely robust and reliable service which has a high uptime and extremely fast server response time. We do everything in our power to keep these promises and have built-in customer protection in our Service Level Agreement

Tooling and Documentation

We have free and open-source tools built around our API. Our Python and Ruby SDK’s, which can be found on Github, are the latest additions to our fleet. We also have plans for upcoming mobile SDK’s which will make it easier than ever to produce software for iOS and Android with real estate data.

Experience

Even seasoned developers will have to go through a learning curve with RETS. Most vendor software we work with has quirks that do no follow the RETS standard to the letter. Other times, there are MLS issues such as bandwidth, throttling, and other technical hurdles that are learned through experience.

Our team specializes in RETS software and we work regularly with some of the largest vendors in the United States and Canada.

If you’re interested in learning more, feel free to shoot us an email at support at simplyrets dot com. We are happy to answer any questions you may have.

You can get started prototyping immediately by creating an account and using our freely available test listings.