FAQ

Is the field ModificationTimestamp always updated?

Is the ModificationTimestamp of a parent resource such as Property, Member, Office always updated when a child resource such as PropertyRooms, PropertyUnit, Media, OtherPhone is updated?

Yes, the ModificationTimestamp of the parent resource is always updated when a child resource is updated. This is not the case for linked resources however.

For example,

• If a Property is updated, Property.ModificationTimestamp will be updated.
• If one of the Property.Rooms is updated, the Property.ModificationTimestamp will be updated.
• If the Office referenced by the Property.ListOfficeKey changes its name, the Office.ModificationTimestamp will be updated but the Property.ModificationTimestamp will not be updated.

---

Should we use webhooks?

The documentation mentions webhooks as an optional replication process, should we use it?

Webhooks are an optional replication process to get resource updates as soon as they are done which is convenient to get updates quickly. However, they are not yet configured to return only your own data. This optimization is planned for a future development phase. Also, this process is not as resilient as pulling and reconciling; if there is an error in the process (e.g. your endpoint which receives the webhook notification fails) or delays (e.g. too many notifications to send), the API may interrupt webhooks for a certain period of time.

You should always implement pulling and reconciling, then optionally support them with webhooks.

---

When to delete a resource?

Is there a field or mechanism to allow us to know when a resource should be deleted from our system?

When a resource that you have access to is updated, its ModificationTimestamp is updated. When that resource is no longer accessible to you, its ModificationTimestamp is still updated but the API will no longer return it.

• If you were to request the resource by its key, the API would return a 404 - Not Found response. This is an indicator that you should probably delete the resource from your system.
• In the case of a deleted child resource such as PropertyRooms, PropertyUnit, Media, etc. the resource will no longer be returned as part of the parent’s collection such as Property.Rooms, Property.Units, Property.Media, etc.

The mechanism to detect all resources that should be deleted is part of the reconciliation process.

For example,

1. You pull the Property with a ListingKey of 1234 and its children Rooms and create that record in your system.
2. After some time, the Property.MlsStatus is set to Expired so its ModificationTimestamp is updated in the API but because you don’t have access to expired listings, it is no longer returned by the API.
3. When pulling properties by their ModificationTimestamp you never receive this update.
4. However, if you reconcile your properties by comparing the list of ListingKey and ModificationTimestamp with the API, your system should notice that the ListingKey 1234 is no longer returned by the API.
5. If you were to request /Property('1234'), the API would return a 404 - Not Found response.
6. You should delete the Property with a ListingKey of 1234 and its children Rooms from your system.

---

Where do we get information about the third and fourth list agents?

The API returns a ListAgentKey and CoListAgentKey but there can be up to four list agents, where are the other two?

The RESO standard only supports two list/buyer agents and there is no support for a collection of agents.

We created the field Property.ListAgentOffices which is a collection of list agents and their offices to allow us to have more than two list agents. We suggest using the Property.ListAgentOffices field instead of ListAgentKey and CoListAgentKey as this collection contains the first, second, third, etc. list agents and offices.

• Use PropertyListAgentOffice.Order to know which one is the first, second, etc.
• Use PropertyListAgentOffice.ListAgentKey to get the key of the list agent.
• Use PropertyListAgentOffice.ListOfficeKey to get the key of the list office.