API Version 2.0
This page contains the information about how to use version 2.0 of the API.
Please see the RESO Enums To Lookups Transition doc for changes that went live March 8, 2022 at 8pm MT and completed by 10pm MT.
API Access
To get data, target the odata based Web API like so:
With the following header
Header | Value |
Authorization | Bearer access_token |
Explanation of the URI segments
The URL shown above has the following segments (with explanations)
Segment | Description |
https://api.mlsgrid.com/v2/ | The main location of the API Service for now and the future |
Property | The resource name for the data that you want to download |
$filter | Using an odata query. This is limited for replication purposes. |
$expand | Contains the list of expanded resource types you want included in the returned data. |
All data is compressed using gzip compression to shrink the overall payload size.
Limitations of Replication API
At this writing there are several limitations imposed on the Web API for the purpose of replication. These limitations are imposed to make the generally heavy odata faster for this specific use case.
Here are limitations imposed:
Limitation | Description |
Each request must contain a single OriginatingSystemName specified in the filter criteria of the request. | |
Searchable Fields | There are only a few fields you can query the service with. This includes timestamp and status fields. See below for a list of all fields. |
$expand calls | $expand is limited to specific resources and types due to the custom nature of our API service. Please see the Expanded Resources section of the docs for more information. We do not support $select or $orderby on the $expand resources. NOTE: If you use expand in the request, the records per request limit reduces to 1000 at most per request. If you set $top=2000 or 5000 for example you will receive an error. |
5000 records per request | You can receive at most 5000 records per request. If you set $top=6000, for example, you will receive an error. The application will default to 500 records per request if not specified. |
or operator | The query must include no more than 5 'or' operators per query. NOTE: It is preferred to use the in operator instead which is new in version 2.0. |
Otherwise, users can select for specific fields as expected using the $select param in the URL.
Replication
Here are some examples of how you will use this API for replication. All examples assume the use of the headers being set properly for authentication purposes.
Initial Import
This is what the initial import request will look like:
The initial import would grab the first "page" of data. We don't want any deleted records so we set MlgCanView to being "equal" to true.
Next Link
To get the next page of data from the request, as part of the response body you will find a field called @odata.nextLink which contains a url. You can use this url as the next request to page through the data. You would continue to use the next link to get the next page of data until the response no longer contains a next link. Here is a snippet that shows what the next link looks like in the json.
Errors during import
If you encounter an error during your initial import you can avoid re-downloading any records that you already received and continue where you left off by adding the ModificationTimestamp that you last received to the initial import query:
We order our requests by ModificationTimestamp by default so that you do not miss changes that occur during your download and so that you can pick up where you left off in this manner.
After Initial Import
After you have the initial data fully downloaded, you would switch to using replication queries which do not contain an MlgCanView filter in them. This allows you to get all changes to the data including changes to MlgCanView=false so that you know when data is removed from the feed and needs to be deleted from your local data store. If you choose to store only a subset of the data in your local data store, your replication queries need to contain the greatest ModificationTimestamp you have received in the data from the api regardless of whether or not you choose to store the records you receive. This avoids repulling the same data over and over again.
Here is an example replication query:
This should be very familiar to anyone who has used RETS before and needed to replicate over that service.
Signal Fields
The following fields when they have changed indicate that action must be taken by the consumer with regard to their local data store.
Resource or Expanded Resource | Field | Action to Take |
ALL | ModificationTimestamp | The record data has changed, replace the contents of your local copy of the record with the updated copy received during replication. |
ALL | MlgCanView | When changed to false, the record is no longer valid for the feed type you consume and must be removed from your local data store. |
Property, Member, Office | PhotosChangeTimestamp | This value will not change without also having the ModificationTimestamp change. If this timestamp changes, it means that the media records have changed. Replace the contents of your local copy of any media records with the updated copies received during replication. Pay attention to any MediaModificationTimestamp updates as noted below. |
Media | MediaModificationTimestamp | This value exists on the Media subdocuments of a Property, Member, or Office record. None of these values will change without also having the ModificationTimestamp of the Property, Member, or Office record change. During regular replication, if the MediaModificationTimestamp of a media record is new or different from what you had before, the image file has changed and needs to be re-downloaded using the MediaURL of the media record. |
Here is an example of a typical sequence of events for how to use these signal fields when receiving updates to records.
Query the API for updates using the greatest ModificationTimestamp from your local database for this resource.
While saving each record received, take the following steps:
Look to see if the MlgCanView field is false. If it is, delete or mark your local data copy to be deleted asynchronously from your data set.
Look to see if the PhotosChangeTimestamp has changed since the last time you received this record. If it has changed, then replace your local media records with the ones you've received in the update.
The key of the Media record is the MediaKey. Match up your records by the MediaKey. As you replace each media record by its MediaKey, look to see if the MediaModificationTimestamp has changed. If it has changed, re-download or mark to re-download asynchronously the image file using the MediaURL for this media record.
If the MediaKey no longer exists mark that record deleted or to delete asynchronously.
After taking all needed action, save off the ModificationTimestamp as the greatest ModificationTimestamp you have received back from the API for this resource and then repeat for the next record.
Metadata
Use this endpoint to access the metadata for the API.
Resource Naming
The following is a list of the resource names (or entity sets) to use in the request URL.
Resource Endpoint | Expandable Resources | Description |
Property | Media, Rooms, UnitTypes | Property Resource. This resource contains all listings for sale or lease. |
Member | Media | Member Resource |
Office | Media | Office Resource |
OpenHouse | - | OpenHouse Resource |
Lookup | - | Lookup Resource |
Expanded Resources
The expanded resources are a sub document of the resource that they belong to. For example the Media records exist as an array of records called Media on the Property Record and are given through the api as part of the Property record. If the ModificationTimestamp of the Property record changes, the contents of the Media sub document should be replaced by whatever is returned in the updated record.
The following is a list of the expandable resources and their corresponding Resource Names that have the ability to expand them. This is basically the same list as above but inverted:
Expanded Resource Name | Resources that can expand this resource | Description |
Media | Property, Member, Office | Media expandable resource. These are the media files associated with a Property, Member, or Office record. |
Rooms | Property | Rooms expandable resource. These are the Room records associated with a Property record. |
UnitTypes | Property | UnitTypes expandable resource. These are the UnitType records associated with a Property record. |
Rooms and UnitTypes
RESO expects these expanded collections to be named differently on the records they are expanded onto. These collections are referenced in the nav links in the resource metadata. This is how the requests and data look:
Metadata
The field name of the data in the Property or other resource record will match the name in the nav link located in the resource it expands from. The Type of the nav link will indicate what EntityType that field name corresponds to so that you can find the definition for that expanded type in the metadata.
Example Metadata Nav Links:
Example Expand Request:
Example Rooms Expanded Data:
Example UnitTypes Expanded Data:
Deleted Records
MlgCanView - Deleted Listings, Off Market Listings, Etc
Each record in the system has a field called MlgCanView which is a boolean field and indicates whether the record should be kept in your database or not. This is how we have implemented our delete mechanism. When you receive an updated record during replication, you should first check this flag to see what action to take with your local copy of the record.
IF true, then save or update the existing record in your db.
IF false, then remove the record from your database (or never save it in the first place).
This value can be changed to false based on a number of different reasons. The following are a few example reasons:
The property was deleted.
The property listing office decided that they don't want to feed out any of their listings.
The property changed status and made it unavailable in IDX
Etc.
PLEASE NOTE: After 7 days records marked MlgCanView false will be removed from the data feed entirely.
The MlgCanView field is a specific field to the MLS Grid that tells you whether the record should be kept in your database. (note that any field with the prefix "Mlg" is specific to the Grid)
Deleted Expanded Resource Records
There is no delete flag for expanded resources as they exist as a part of the record they come with. As is the case with all other fields on the record, if you get records or values that are different than what you currently have, replace it with the new records and values you've received. If some of the data in your local data store no longer exists in the updated data that you received, remove it.
MlgCanUse Field
Each record in the system has a field called MlgCanUse which is an array that helps indicate which of the Use Cases defined in the MLS Grid Master Data License Agreement the record qualifies for.
Each of the values in this field correspond to the data subscription types where the record may be found, and the possible Use Cases for each data subscription type are detailed below.
IDX Data Subscriptions
Records marked for IDX can be used in the Internet Data Exchange Program for public display on IDX websites AND in Customer Relationship Management and Transaction management tools.
Example MlgCanUse Field Output for IDX
VOW Data Subscriptions
Records marked for VOW can be used in the Virtual Office Website Program whereby a Internet website or a feature of a website is capable of providing real estate brokerage services to consumers where there exists a broker-consumer relationship. Additionally if the MlgCanUse field contains the IDX value, the records can also be used for the IDX Use Cases detailed above. Records that contain ONLY the VOW value can not be used for IDX Use Cases.
Example MlgCanUse Field Output for VOW
Back Office (BO) Data Subscriptions
Records marked for Back Office (BO) can be used in Agent Production Analytics, Comparative Market Analysis, Real Estate Market Analytics, and Participant Listings Use (as each is defined in the MLS Grid Master Data License Agreement). Additionally if the MlgCanUse field contains the IDX and VOW values, the records can also be used for the IDX and VOW Use Cases detailed above. Records that contain ONLY the BO value can not be used for IDX or VOW Use Cases.
Example MlgCanUse Field Output for Back Office (BO)
Broker Only / Participant Data Access (PT) Data Subscriptions
Records marked for Broker Only / Participant Data Access (PT) can be used solely for Participant Listings Use (as defined in the MLS Grid Master Data License Agreement).
Example MlgCanUse Field Output for Broker Only / Participant Data Access (PT)
Example MlgCanUse Field Metadata
The MlgCanUse field can be found in the MLS Grid Metadata for each MLS.
Media
The expanded media contains data describing photos associated with Properties, Members, and Offices.
The primary identifier of the media records is the MediaKey field. This is the field that uniquely identifies a record.
In order to retrieve the photo associated with the media record, you will need to use the url provided in the MediaURL field to download the image. The url is for the highest resolution photo that the MLS provides to us.The URLs contained in the Media resource are to be used ONLY for the purpose of downloading a local copy of the image file. DO NOT use these URLs on your website or in your application.
Lookups
This resource contains all of the lookup values for an mls. We recommend using the following queries to replicate and keep your Lookup data up to date:
Initial Data Import Request
Regular Replication Requests
Replicate from this resource the same way you would replicate from any of the resources using the Greatest ModificationTimestamp from the records you've received so far when querying for the latest changes.
Please do not pull from this resource more frequently than once a day as this resource will not likely change more than once a day. Pulling this resource with the same frequency as the rest of the resources may result in interruption of service for inefficient usage practices.
If you receive an update to MlgCanView: false on any of your lookup records, you should remove it from the list of possible values for that LookupName for the OriginatingSystemName on the record.
Example Lookup Record
The LookupKey is the primary identifier for this resource. Each record indicates that a lookup exists and is being used or not used by a particular mls depending on the value of the MlgCanView flag. The ModificationTimestamp will update whenever the Lookup record has changed.
Example Field Metadata with a Lookup:
Fields that have a lookup collection associated to it will appear like this in the metadata. In these 2 cases, the BodyType field uses a Lookup with the LookupName of BodyType in the Lookups collection. Possible values for this field can be found by looking in your local copy of the Lookups data for values assocated to the BodyType lookup. Same For StandardStatus. Lookup values for StandardStatus have a LookupName of StandardStatus in the lookups collection and you can search your local copy of the lookups collection for values associated with the StandardStatus Lookup.
Example of These 2 Lookups from the Lookups Resource:
BodyType
StandardStatus
Searchable Fields
To keep performance as optimal as possible, we restrict searching on our replication odata server to the fields that are required for replication consumers. The tables below detail those fields.
Property
Searchable Property Field | Description |
This field is a required search field on every request in version 2.0 of the API. This field is the MLS Grid name for the Originating System. | |
ModificationTimestamp | The timestamp that the record was last modified by the MLS Grid. |
The standard status field (values are 'active', 'closed', etc) | |
The property type field (values are 'Residential','CommercialSale', etc) | |
ListingId | The prefixed MLS id of the listing record. |
Whether or not the record is allowed to be included in the feed type you are requesting. | |
ListOfficeMlsId | The prefixed MLS id of the office record that the record was listed by. |
Member
Searchable Member Field | Description |
This field is a required search field on every request in version 2.0 of the API. This field is the MLS Grid name for the Originating System. | |
ModificationTimestamp | The timestamp that the record was last modified by the MLS Grid. |
MemberMlsId | The prefixed MLS id of the member record. |
Whether or not the record is allowed to be included in the feed type you are requesting. |
Office
Searchable Office Field | Description |
This field is a required search field on every request in version 2.0 of the API. This field is the MLS Grid name for the Originating System. | |
ModificationTimestamp | The timestamp that the record was last modified by the MLS Grid. |
OfficeMlsId | The prefixed MLS id of the office record. |
Whether or not the record is allowed to be included in the feed type you are requesting. |
OpenHouse
Searchable OpenHouse Field | Description |
This field is a required search field on every request in version 2.0 of the API. This field is the MLS Grid name for the Originating System. | |
ModificationTimestamp | The timestamp that the record was last modified by the MLS Grid. |
OpenHouseKey | The prefixed MLS key of the open house record. |
ListingId | The prefixed MLS id of the property record associated with the open house record. |
MlgCanView | Whether or not the record is allowed to be included in the feed type you are requesting. |
OpenHouseDate | The date that the open house will take place. |
Lookup
Searchable Lookup Field | Description |
This field is a required search field on every request in version 2.0 of the API. This field is the MLS Grid name for the Originating System. | |
ModificationTimestamp | The timestamp that the record was last modified by the MLS Grid. |
LookupName | The name of the Lookup you want to get the records for. |
Whether or not the record is still being used by the OriginatingSystem. | |
LookupKey | The mls prefixed key - primary identifier of the lookup. |
Broker Only Searchable Fields
Broker Only Export feed has a more restricted set of fields that can be searched. The following fields are minimal for the purposes of replicating the records for this feed type.
Property
Searchable Property Field | Description |
This field is a required search field on every request in version 2.0 of the API. This field is the MLS Grid name for the Originating System. | |
ModificationTimestamp | The timestamp that the record was last modified by the MLS Grid. |
ListOfficeMlsId | The prefixed MLS id of the office record that the record was listed by. |
Whether or not the record is allowed to be included in the feed type you are requesting. |
Member
Searchable Member Field | Description |
This field is a required search field on every request in version 2.0 of the API. This field is the MLS Grid name for the Originating System. | |
ModificationTimestamp | The timestamp that the record was last modified by the MLS Grid. |
OfficeMlsId | The prefixed MLS id of the office associated with the member record. |
Whether or not the record is allowed to be included in the feed type you are requesting. |
Office
Searchable Office Field | Description |
This field is a required search field on every request in version 2.0 of the API. This field is the MLS Grid name for the Originating System. | |
ModificationTimestamp | The timestamp that the record was last modified by the MLS Grid. |
OfficeMlsId | The prefixed MLS id of the office record. |
Whether or not the record is allowed to be included in the feed type you are requesting. |
OpenHouse
Searchable OpenHouse Field | Description |
This field is a required search field on every request in version 2.0 of the API. This field is the MLS Grid name for the Originating System. | |
ModificationTimestamp | The timestamp that the record was last modified by the MLS Grid. |
ListOfficeMlsId | The prefixed MLS id of the office record of the listing record associated with the open house record. |
MlgCanView | Whether or not the record is allowed to be included in the feed type you are requesting. |
OriginatingSystemName
The OriginatingSystemField is a field we use to indicate which system a record has originated from. The values in this field are case sensitive and usually all lowercase. The possible values for OriginatingSystemName are as follows:
OriginatingSystemName | Originating System |
actris | ACTRIS MLS |
carolina | Canopy MLS |
flinthills | Flint Hills MLS |
scranton | Greater Scranton Board of REALTORS® |
nira | Northwest Indiana REALTORS® Association (formerly GNIAR) |
hmls | Heartland Multiple Listing Service, Inc. |
highland | Highland Lakes Association of REALTORS® |
lbor | Lawrence Board of REALTORS® |
lascruces | Southern New Mexico MLS |
maris | MARIS MLS |
mfrmls | My Florida Regional MLS DBA Stellar MLS |
mibor | MIBOR REALTOR® Association |
mlsok | MLSOK |
mred | MRED Midwest Real Estate Data |
neirbr | Northeast Iowa Regional Board of REALTORS® |
nocoast | NoCoast MLS |
northstar | NorthstarMLS® |
nwmls | Northwest MLS |
onekey | OneKey® MLS |
paar | Prescott Area Association of REALTORS® |
pikewayne | Pike/Wayne Association of REALTORS® |
prairie | Mid-Kansas MLS (Prairie Land REALTORS®) |
ranw | REALTOR® Association Northeast Wisconsin |
realtrac | RT RealTracs |
recolorado | REcolorado |
rmlsa | RMLS Alliance |
rrar | Reelfoot Regional Association of REALTORS® |
sarmls | Spokane Association of REALTORS® |
sckansas | South Central Kansas MLS |
somo | Southern Missouri Regional MLS (SOMO) |
spartanburg | Spartanburg Board of REALTORS® |
sunflower | Sunflower MLS |
Searchable Fields with Lookups
The PropertyType and StandardStatus fields are defined in the Lookups collection. You can search by the lookup value for these fields when performing a request.
Example Query by StandardStatus Request:
StandardStatus
Querying by the StandardStatus field is a special case because it is enumerated. The following example shows the syntax needed.
To get all of the records that have an Active Under Contract StandardStatus, you must use the name of the status in order to query for it. (Note that in the table below the name is 'ActiveUnderContract' without spaces. These names are also contained in the StandardStatus enumeration metadata in the API but are provided here for convenience).
This is the syntax for a request for all records with an Active Under Contract StandardStatus value:
The following are the RESO Standard Status values we provide:
Name | Value | Standard Name |
Active | 1 | Active |
ActiveUnderContract | 2 | Active Under Contract |
Canceled | 3 | Canceled |
Closed | 4 | Closed |
ComingSoon | 5 | Coming Soon |
Delete | 6 | Delete |
Expired | 7 | Expired |
Hold | 8 | Hold |
Incomplete | 9 | Incomplete |
Pending | 10 | Pending |
Withdrawn | 11 | Withdrawn |
PropertyType
Querying by the PropertyType field is a special case because it is enumerated. The following example shows the syntax needed.
To get all of the records that have a PropertyType value of 'Commercial Sale', you must use the name of the PropertyType in order to query for it. (Note that in the table below the name is 'CommercialSale' without spaces. These names are also contained in the PropertyType enumeration metadata in the API but are provided here for convenience).
This is the syntax for a request for all records with a Commercial Sale PropertyType value:
The following are the RESO Property Type values we provide:
Name | Value | Standard Name |
BusinessOpportunity | 1 | Business Opportunity |
CommercialLease | 2 | Commercial Lease |
Commercial Sale | 3 | Commercial Sale |
Farm | 4 | Farm |
Land | 5 | Land |
ManufacturedInPark | 6 | Manufactured In Park |
Residential | 7 | Residential |
ResidentialIncome | 8 | Residential Income |
ResidentialLease | 9 | Residential Lease |
Local Fields Prefix
Local fields specific to an MLS have been prefixed to identify which MLS they originate from. The local field prefixes are:
Local Field Prefix | Originating System |
ACT_ | ACTRIS MLS |
CAR_ | Canopy MLS |
FHR_ | Flint Hills MLS |
GSB_ | Greater Scranton Board of REALTORS® |
NRA_ | Northwest Indiana REALTORS® Association (formerly GNIAR) |
HMS_ | Heartland Multiple Listing Service, Inc. |
HLM_ | Highland Lakes Association of REALTORS® |
LCN_ | Southern New Mexico MLS |
LBR_ | Lawrence Board of REALTORS® |
MAR_ | MARIS MLS |
MBR_ | MIBOR REALTOR® Association |
MFR_ | My Florida Regional MLS DBA Stellar MLS |
MRD_ | MRED Midwest Real Estate Data |
NBR_ | Northeast Iowa Regional Board of REALTORS® |
NOC_ | NoCoast MLS |
NST_ | NorthstarMLS® |
NWM_ | Northwest MLS |
OKC_ | MLSOK |
ONE_ | OneKey® MLS |
PAR_ | Prescott Area Association of REALTORS® |
PWB_ | Pike/Wayne Association of REALTORS® |
PRA_ | Mid-Kansas MLS (Prairie Land REALTORS®) |
RAN_ | REALTOR® Association Northeast Wisconsin |
REC_ | REcolorado |
RMA_ | RMLS Alliance |
RRA_ | Reelfoot Regional Association of REALTORS® |
RTC_ | RT RealTracs |
SAR_ | Spokane Association of REALTORS® |
SCK_ | South Central Kansas MLS |
SOM_ | Southern Missouri Regional MLS (SOMO) |
SPN_ | Spartanburg Board of REALTORS® |
SUN_ | Sunflower MLS |
Prefixed KeyField Values
In order to maintain uniqueness across IDs, it is necessary to prefix our Key and MlsId fields throughout the data. Any field that is a Key or an MlsId field or is a reference to a Key or MlsId field in one of our other resources will be prefixed with an MLS specific prefix. This prefix should be removed from the data prior to displaying externally but must be added back whenever requesting records within the MLS Grid.
Here are a few examples:
If my ListingKey for a record in the MLS system was '123456' and my MLS's prefix was 'ACT', I would search in the MLS Grid for a record with a ListingKey equal to 'ACT123456'. If I wanted to display this record on my website, I would display '123456' as the key on my website.
If I have a problem with the OpenHouse records for one of my properties and I need to troubleshoot this specific record I might search for OpenHouse records by the MlsId of the property record. To find open house records for a property record, if the MlsId for the MLS's property record was '456789' and the MLS's prefix was 'ACT', I would search the OpenHouse resource for records where the ListingId is equal to 'ACT456789'.
Finally, if I wanted to find the Member record in the MLS Grid for an MLS's property record with a ListAgentMlsId of 'A10001', I would search the Member resource for the MemberMlsId equal to 'ACTA10001'. If I also search for the Property record from the MLS Grid, I can expect that the ListAgentMlsId in the data would be equal to 'ACTA10001' which would match the MemberMlsId of the Member resource record I received.
PLEASE NOTE: Non-Alphanumeric characters can create issues with oData and the RESO Web API. For this purpose special characters must be stripped from the values provided in key fields.
The following are the Key and MlsId prefixes for each MLS source:
KeyField Prefix | Originating System |
ACT | ACTRIS MLS |
CAR | Canopy MLS |
FHR | Flint Hills MLS |
GSB | Greater Scranton Board of REALTORS® |
NRA | Northwest Indiana REALTORS® Association (formerly GNIAR) |
HMS | Heartland Multiple Listing Service, Inc. |
HLM | Highland Lakes Association of REALTORS® |
LCN | Southern New Mexico MLS |
LBR | Lawrence Board of REALTORS® |
MAR | MARIS MLS |
MBR | MIBOR REALTOR® Association |
MFR | My Florida Regional MLS DBA Stellar MLS |
MRD | MRED Midwest Real Estate Data |
NBR | Northeast Iowa Regional Board of REALTORS® |
NOC | NoCoast MLS |
NST | NorthstarMLS® |
NWM | Northwest MLS |
OKC | MLSOK |
ONE | OneKey® MLS |
PAR | Prescott Area Association of REALTORS® |
PWB | Pike/Wayne Association of REALTORS® |
PRA | Mid-Kansas MLS (Prairie Land REALTORS®) |
RAN | REALTOR® Association Northeast Wisconsin |
REC | REcolorado |
RMA | RMLS Alliance |
RRA | Reelfoot Regional Association of REALTORS® |
RTC | RT RealTracs |
SAR | Spokane Association of REALTORS® |
SCK | South Central Kansas MLS |
SOM | Southern Missouri Regional MLS (SOMO) |
SPN | Spartanburg Board of REALTORS® |
SUN | Sunflower MLS |
Array of Strings
RESO expects fields defined as type 'String List, Multi' to be returned as an array of strings. We output these fields as an array of multiple string values.
Example field output
At the time of this documentation, these are the fields that we have in our data that are of type 'String List, Multi'. To get a complete list, please use RESO's documentation.
Property
AccessibilityFeatures |
Appliances |
ArchitecturalStyle |
AssociationAmenities |
AssociationFeeIncludes |
Basement |
BodyType |
BuildingFeatures |
BusinessType |
BuyerAgentDesignation |
BuyerFinancing |
CoBuyerAgentDesignation |
CoListAgentDesignation |
CommonWalls |
CommunityFeatures |
ConstructionMaterials |
Cooling |
CurrentFinancing |
CurrentUse |
DevelopmentStatus |
Disclosures |
DocumentsAvailable |
Electric |
ExistingLeaseType |
ExteriorFeatures |
Fencing |
FinancialDataSource |
FireplaceFeatures |
Flooring |
FoundationDetails |
FrontageType |
GreenBuildingVerificationType |
GreenEnergyEfficient |
GreenEnergyGeneration |
GreenIndoorAirQuality |
GreenSustainability |
GreenWaterConservation |
Heating |
HorseAmenities |
HoursDaysOfOperation |
InteriorFeatures |
IrrigationSource |
LaundryFeatures |
Levels |
ListAgentDesignation |
ListingTerms |
LockBoxType |
LotFeatures |
OperatingExpenseIncludes |
OtherEquipment |
OtherStructures |
OwnerPays |
ParkingFeatures |
PatioAndPorchFeatures |
PetsAllowed |
PoolFeatures |
Possession |
PossibleUse |
PowerProductionType |
PropertyCondition |
RentIncludes |
RoadFrontageType |
RoadResponsibility |
RoadSurfaceType |
Roof |
RoomType |
SecurityFeatures |
Sewer |
ShowingContactType |
ShowingRequirements |
Skirt |
SpaFeatures |
SpecialLicenses |
SpecialListingConditions |
StructureType |
SyndicateTo |
TenantPays |
UnitTypeType |
Utilities |
Vegetation |
View |
WaterfrontFeatures |
WaterSource |
WindowFeatures |
Media
Permission
Rooms
RoomFeatures
Member
SyndicateTo
Office
SyndicateTo
Appendix
This includes other information that might be important to better understand the MLS Grid service.
Example Property Data
Here is an example of a single property record from Actris:
Last updated