Welcome to HIS RETS Support

Hawaii Information Service has implemented and supports RETS Version 1.7.2. This site has been developed to provide you with the information and resources necessary to understand and implement RETS. Undertaking a RETS implementation requires proficiency in managing databases and communications protocols. If you do not have technical resources available to you HIS offers a plug and play IDX solution.

What is RETS?

From Wikipedia, the free encyclopedia

RETS is an acronym which stands for Real Estate Transaction Standard RETS was created to overcome the difficulties presented by the existence of a large number of organizations desiring to share and distribute real estate information with others. RETS addressed this need by providing a common standard for the exchange of real estate data. Many MLS data exchange service providers use the RETS protocol.

The Real Estate Transaction Standard (RETS) facilitates data transfer between partners in the real estate industry. Creating and improving RETS is a collaborative effort to simplify moving real estate information from system to system and simplify solution development efforts. As RETS usage matures and expands, MLS with geographic overlaps can create data-sharing policies that provide their members a single point of entry to search multiple MLS data sets.

RETS Benefits

• Provides the ability to download REsearch MLS data for use in your consumer and VOW websites.
• Up to the minute data is available through the HIS RETS server.
• New RETS based products will be available in the market.
• Plain English

HIS RETS Fields and Metadata

This Metadata contains a list of fields for all resources available to your feed type. Please note that different resources are on different tabs of the excel spreadsheet.

Each row of the spreadsheet represents one field.

• RETS IDX – last updated September, 2019 (XLSX format)
• RETS VOW – last updated September, 2019 (XLSX format)

HIS Variman RETS 1.7.2 Server Implementation

HIS has implemented Variman RETS Server Version 3.2.0b1. Variman is developed under a BSD-style license at the Center for REALTOR(R) Technology. This PDF of Available RETS Fields Attached contains the table of contents from the RETS 1.7.2 specification in the left column. The right column shows ‘Reference’ if the item is for reference only, ‘Yes’ if this feature exists for the HIS RETS Server, and ‘No’ if this feature does not exist.

The HIS Variman RETS Server provides real-time access to the REsearch database. RETS users have 24/7 access to the REsearch database. Each RETS user is assigned a RETS profile that defines what information they are allowed to access. The three most common profiles are VOW, IDX and TAX. The VOW profile provides access to all Listings and is designed to provide data for Virtual Office Websites. The IDX profile is limited to active and contingent statuses and only the fields allowed to be displayed on consumer facing websites. The TAX profile consists of only Tax data, no listing, agent or office information is available.

Output Formats

The HIS Variman RETS 1.7.2 Server supports COMPACT and COMPACT Decoded formats. Standard-XML format is NOT supported. See Section 13 of this specification

RETS Transactions

Access to the HIS RETS Server is accomplished by performing transactions. A brief description of each HIS supported transaction is listed below. Click on the Transaction to go directly to the full specification.

Login

A client MUST issue a login request prior to proceeding with any other request. The Login transaction verifies all login information provided by the user and begins a RETS session. Subsequent session control may be mediated by HTTP cookies or any other method, though clients are required to support at least session control via HTTP cookies.

The server’s response to the Login transaction contains the information necessary for a client to issue other requests. It includes URLs that may be used for other RETS requests, and may also contain identity and parameter information if required by the functions supported by the server.

GetMetadata

The GetMetadata transaction is used to retrieve structured information known as metadata related to the system entities. Metadata requested and returned from this transaction are requested and returned as MIME media types.

Search

The Search transaction requests that the server search one or more searchable databases and return the list of qualifying records. The body of the response contains the records matching the query, presented in the requested format. The data can be returned in two formats: COMPACT or COMPACT-DECODED and are further explained in the Output Formats section of this site.

GetObject

The GetObject transaction is used to retrieve structured information related to known system entities. It can be used to retrieve multimedia files and other key-related information. Objects requested and returned from this transaction are requested and returned as MIME media types. The message body for successful retrievals contains only the objects in the specified MIME media type. Error responses follow the normal response format (RETS spec section 3.9).

Logout

The Logout transaction terminates a session. Except in cases where connection failure prevents it or the user has requested an immediate shutdown of the client, the client SHOULD send the Logout transaction. If the client sends a Logout transaction, the server MUST attempt to send a response before terminating the session.

The server MAY send accounting information back to the client in the response to this transaction. The client is not required to display or otherwise process the accounting information.

Glossary

BNF
Backus-Naur form. A formal description of syntax used within a standard. The BNF description will show, for example, what characters can and cannot be used as a specific value.

Certification Workgroup
RETS Workgroup responsible for providing direction to the Compliance Testing Workgroup regarding what compliance tests are necessary for certification as RETS compliant. This Work Group’s primary objective for the next 90 days is to help MLSs adopt the new NAR MLS policy for RETS to be adopted by mid 2009

Class
A sub-category of a RETS Resource. For example, the Property Resource may have RESI, COMI, LOTL, etc. as Classes.

Client
A software application which runs on a computer and relies on a server to perform some operations. For example: Microsoft Outlook may be your email client while Microsoft Exchange is the server which routes and stores your emails

Compact
A RETS client can request that the results to a query be in COMPACT format. The most basic explanation is that this is a tab-delimited file and the idea is that the bandwidth requirements are less than for representing the same data in STANDARD-XML format. Lookup data is provided in it’s coded format. COMPACT and COMPACT-DECODED formats will generally require that the client software utilize the server’s metadata to fully understand the fields presented.

Compact Decoded
Similar to COMPACT format, COMPACT-DECODED results are usually tab delimited. The major difference between COMPACT-DECODED and COMPACT is that COMPACT-DECODED results will have Lookup data in it’s most human readable format–coded fields will be expanded to something that is generally understandable to humans. Like COMPACT format, the client software will need to utilize the server’s metadata to fully understand the fields presented.

Compliance / Compliancy
Once a RETS client or RETS server has been developed, a Compliance test can be run to make sure that it follows the RETS standard. The tests are defined and designed by the Compliance Testing Workgroup.

Compliance Testing Workgroup
RETS Workgroup responsible for developing tools to test the compliance of RETS implementations.

DTD
Document Type Definition. These files are used to describe an XML document so a computer program can automatically “learn” how the XML is structured and what data types are used.

Data Elements
Pieces of information delivered from a server after a query and may include field values, images, URL’s, etc.

Data Recipient
Person or entity which receives, pulls or accesses MLS content.

Data Schemas Workgroup
RETS Workgroup tasked to define the XML Schemas for instance documents that contain MLS information.

Database Name
The unique identifier the MLS database uses to name a field. Some MLS databases use numeric database names.

Database Server
The “backend” MLS system server which houses property, agent, office information as well as images, documents, etc. A database server is proprietary to the MLS vendor and works in conjunction with the MLS system software

FTP
File Transfer Protocol. FTP is a file transfer standard for moving static files from one computer to another.

Filtering
Applying rules to a User Agent, User Class, etc. which limits the data elements, amount of data, number of queries returned by a request for a specific User, User Class, User Agent, etc.

GUI
Graphical User Interface

GetObject
A RETS request type. The GetObject request is issued from a RETS client to a RETS server in order to obtain objects for a specific listing such as property photos or PDFs. The request can be for a single, specific object or can be issued to retrieve all objects.

HTTP
Hypertext Transfer Protocol. HTTP is the protocol the RETS 1.x family of versions use for communicating back and forth. Authentication is typically accomplished using either Basic or Digest authentication within HTTP. Request-specific values are passed to the server within the URL while the body of the response is returned back to the client in the HTTP body.

IDX
Internet Data eXchange. At it’s core, IDX is the concept of displaying property information from an MLS on an Internet website, although over the years, IDX has taken on different meanings. An “IDX feed” or “IDX file” is typically an exported file (once every 24 hours or so) that resides on an FTP server controlled by the MLS. “IDX vendor” is a term used to describe a 3rd party company that provides a product or service that makes use of data from an MLS.

Lookup
A field that contains preset codes as it’s value. For example: PropertyType might be a field that contains RES as it’s value. Doing a ‘METADATA-LOOKUP_TYPE’ request through RETS would tell you that PropertyType can contain RES (the code) for Residential (it’s value), CON for Condo, LAN for Land, COM for Commercial, etc.

Metadata
Metadata can be thought of as “data describing the data”. When used with RETS, retrieving the Metadata for a specific property class (example: Residential properties) will return very specific information about all of the fields, field types, which fields are searchable, etc. A “Metadata-aware” RETS client can use this information to automatically recognize changes to a data format (like when a field has been added) and adapt accordingly without user intervention (by adding a new field in their local database to make room).

Plugfest
Plugfest is an open workshop for client vendors and server vendors to test their interoperability held during the trimester conferences. This is a popular event where some of the best technical staff from the industry meet to help each other connect using the RETS specification.

Query
A query is made up of different sub queries separated for logical operators. Each sub query can contain Sub Queries, Lookups, Ranges and Strings.

Query Workgroup
RETS Workgroup tasked with defining, developing, testing, and proposing a new query mechanism that simplifies data access in a unified XML payload.

RCP
Rule Change Proposal. An RCP is a document which includes a possible rule change to the specified technical document. Once voted on and approved, the change described would be implemented into the standard.

RESO
Real Estate Standards Organization, a body that is a legal United States Corporation whose purpose is to govern the standards development, promotion, and maintenance activities of RETS and related activities.

RETS
Real Estate Transaction Standard

Request
An action performed against the server, such as a query, call for images, open house URL’s, etc.

Resource
The RETS term for a general category of data available through a RETS server. For example: Property, Agent, Tour, OpenHouse, etc.

SOAP
Simple Object Access Protocol. Provides a way to communicate between applications running on different operating systems, with different technologies and programming languages.

Schema
The structure of a database system, described in a formal language supported by the database. In a relational database, the schema defines the tables, the fields in each table, and the relationships between fields and tables. RETS Schema defines fields, data types and classifications.

Security Workgroup
RETS Workgroup working on establishing SSO standards within the RETS standard. In addition, the Security Workgroup reviews all change proposals for security concerns.

Server
The Server is the central computer system which contains the desired information. A Server handles requests from Clients, applies business rules and other limitations on those requests (through filtering) and provides a valid data response back to the Client.

Syndication Workgroup
RETS Workgroup responsible for defining standardized listing data and transport specification that makes it easy for brokers to syndicate their listings to multiple sites.

The pipe “|”
Means OR so everything separated by commas has is OR’ed.

The plus “+”
Means AND so everything separated by a comma is AND’ed.

The tilde “~”
Means NOT so everything separated by a comma is NOT’ed.

Transport Workgroup
RETS Workgroup which provides technical processes for analyzing extensions to transport methods in current and future versions of the RETS specification.

Update Workgroup
RETS Workgroup tasked with making listing entry easier and reducing the amount of duplicate listing entry for brokers and agents are key goals for the Update workgroup.

User Agent
A User Agent is the name a RETS client goes by and what version is currently being used. For example, a User Agent of RETSclient/1.0 shows that a user is using version 1.0 of a product called RETSclient. This “signature” is provided with each RETS request and can be used for authentication and/or filtering on the server.

User Class
See User Roles

User Roles
A group of users can be assigned specific user roles. Typically, these roles are used in combination with filtering so a group of users are assigned specific filtering. For example, any RETS user who is an IDX vendor can be assigned the “IDX Vendor” role and a specific filter can be applied to the group rather than to each user specifically.

Versioning
Mechanism which tracks all changes in content and code. For RETS, Versioning refers to the number associated or applied to the RETS Standard Documents, i.e. 1.5, 1.7, etc. which have been voted and approved by the RETS Working Group.

Wiki
Informal, unofficial part of a website where anyone can contribute content and collaborate.

Workgroup
A group chartered by the RESO Board of Directors in order to discuss, collaborate and/or develop certain materials. Members of these groups include individuals from companies across various sectors of the real estate industry. Each workgroup has member contributors, a Chair, Vice Chair and a Scribe.

XML
eXtensible Markup Language. XML is a custom markup language used by many general-purpose applications to exchange information. The tags used within XML are not pre-defined and can be anything that correctly describes the data. Data in this format is easy for a program to consume and use, regardless of the operating system or programming language used. Within RETS, the XML tags are pre-defined which make it easier for a single program to understand data that may come from different RETS servers. See Schema for more information.

HIS RETS – common developer questions

IMPORTANT: HIS allows access to RETS by IP. In order to connect to our RETS server, subscribers and their developers will need to submit the IP address of the computer or server that will be making queries. It is recommended that this IP be provided at the beginning of the application process to avoid unexpected service outages. If a subscriber or subscriber’s webmaster has a separate development IP that will be used for testing and development, this secondary IP will be allowed access for a limited time. Talk with your HIS representative for specifics.

Here are a few questions that are commonly asked.

Where is the CountyID? Short answer: there is none. To specify the county you want, you’ll need to use the first digit in the “mls_taxkey” or “taxkey9” column. 1 for Oahu. 2 for Maui. 3 for Hawaii. 4 for Kauai.

Where is City? We don’t really have cities as you may define it on the U.S. mainland. They’re more like towns than anything else. We do have a “city” field in the MLS but it is very under-used (agents rarely ever fill out this field) so building a search filter based on this field will return only a fraction of the listings that you should get if we were to include it in the feed.

Locals would better understand if you use “subdivision” names. You could call it “neighborhood” for those less familiar with Hawaiian localities, but this is the name of the field in the feed. For a comprehensive list of subdivisions, contact your REALTOR client because they have access to such a list through the REsearch MLS system they have.

You can also bump zip codes up against the USPS database and come up with a name. However, zip code boundaries do not always properly define areas as well as subdivision does.

If you’re looking for larger areas, everyone knows “district”. Each island has less than 10 districts and these lines are based on the county records.