API Overview

Our API is an OData-compliant API that follows the RESO Web API Standard. It provides structured access to real estate data in a consistent and standardized way.

Service Document

The service document provides a high-level overview of all the resource endpoints available in the API. It is typically the first endpoint you access to discover what resources you can query.

URL: https://www.realtracs.com/reso/

The service document lists:

• All resource sets (endpoints) you can query
• Links to the metadata document
• Links to individual resources

Accessing the service document allows your client application to dynamically discover available data.

Metadata Endpoint

The metadata endpoint describes the structure of all the entities, properties, and relationships in the API.

• Provides an XML document or JSON document in the OData EDMX format
• Includes:
  • Entity types
  • Complex types
  • Relationships between entities
  • Supported operations

The metadata endpoint is essential for generating strongly typed clients or understanding the data model.

Resource Endpoints

Once you know what resources are available from the service document, you can query individual resource endpoints. Examples of resource endpoints include:

• Listings
• Members
• Offices
• OpenHouses
• Media

Each resource endpoint supports standard OData operations such as:

• $filter — Filter records
• $orderby — Sorting
• $count — Get total number of records
• Query by Primary Key or other supported criteria

Each resource endpoint corresponds to a “resource set” in the OData model, and your application can use these endpoints to retrieve, filter, and navigate data efficiently.

ℹ️ The documentation for each resource endpoint contains a Best Practices section. Be sure to review these Best Practices to maintain the most efficient client and keep your costs low.

Query and Filter Restrictions

By following the RESO Web API standard, our API ensures consistent access patterns across all resources, making integration predictable and efficient.

However, the OData standard allows clients to query on virtually any field. Practically, for performance and reliability, we only support filtering and ordering on a subset of fields that are properly indexed in our database.

This ensures that queries are fast, predictable, and do not overload our servers.

Response Codes for Restricted Queries

• 501 Not Implemented
  Your request was valid OData, but the requested filter or order operation is not supported by our system for performance reasons.

  Example: Trying to $orderby a field that is not indexed may return a 501.

• 403 Forbidden
  Your request may be attempting to filter or order on a field that is restricted by our API.

  Example: Filtering on sensitive fields or unsupported properties will result in a 403.

⚠️ Note: These restrictions are in place to maintain high performance and consistent availability for all users of the API. Review the billing page to ensure you understand the Transaction Class and cost for your requests.

Fetch vs Query

Our OData API supports two primary ways to retrieve records: direct fetch by URL and query using $filter. Understanding the difference is important for both usage and transaction costs.

Fetch by URL

You can retrieve a single record directly using its Primary Key in the URL.

Example:

GET https://www.realtracs.com/reso/Property('123')

• Returns exactly one record.
• Fast and efficient — only one record is accessed.
• Transaction Class: A (Fetch)
• Use this method when you know the exact key of the record you need.

Query with $filter

You can also retrieve records by constructing a $filter expression.

Example:

GET https://www.realtracs.com/reso/Property?$filter=ListingKey eq '123'

• Returns one or more records that match your filter.
• Can combine multiple criteria, $orderby, $top, $count, etc.
• Transaction Class: B (Query)
• ⚠️ Use queries for flexible retrieval when you don’t know the Primary Key. Keep in mind that queries may return multiple records, and transaction costs are higher than a single fetch.

Pagination and NextLink

Our API does not support $skip for paging results. Skipping records is not performant for large datasets, and may impact the reliability of queries.

Instead, the API uses server-driven paging with the @odata.nextLink property.

How @odata.nextLink Works

When a query returns a large number of records:

• The response will include a subset of records (a page).
• If more records are available, the response will include a @odata.nextLink property:

{
  "value": [
    { "OfficeKey": "123", "Name": "Downtown Office", ... },
    { "OfficeKey": "456", "Name": "Uptown Office", ... }
  ],
  "@odata.nextLink": "https://www.realtracs.com/reso/Offices?$top=100&$filter=MemberStatus eq 'Active'&$skiptoken=xyz"
}

• The @odata.nextLink URL contains all the query parameters needed to fetch the next page.

How to Follow the NextLink

1. Take the URL provided in @odata.nextLink.
2. Make a GET request to that URL.
3. Repeat this process until the response does not include @odata.nextLink, which means you have reached the last page.

⚠️ Do not attempt to construct your own $skip values — the server manages paging internally for performance reasons. Always follow the nextLink provided by the API.