Collapse Drawer
Expand Drawer

Direct Web API - Listing (MLO Data) Reference

Access direct listings and other data directly

The Direct Web API now supports programmatic access to direct listings and other data. This allows you to read direct data from the database directly.

How is this different from Trestle's RESO Web API?

The Direct Web API provides access to direct data that varies between Matrix installations. The available tables and fields are defined by each site's metadata and will be different from one Matrix system to the next. Matrix customers can use the Direct Web API to expose all of the unique data directly available in their system and are not limited to the RESO Data Dictionary format.

Available Data Types

Determined by each Matrix customer individually, the available data may include:

  • Direct listing data
  • Listing media
  • Agent/member data
  • Office data
  • Open house information

Other resources that are unique to a particular Matrix installation may also be available. Matrix customers can choose to limit exposure of certain resources (tables, rows, etc.) depending on the application or user.

Data Access

The Direct Web API uses the OData protocol with OpenID Connect (OIDC) authentication to provide secure data access for a specific MLS member. Applications calling the Direct Web API use the member's credentials in the OIDC authentication process to ensure access is appropriately limited according to the user's privileges in Matrix.

Applications may use Clareity Single Sign-On authorization or basic authentication using an individual login and password. All data access is read-only at this time.

Getting Started

The Direct Web API uses Trestle by CoreLogic to manage user accounts, credentials, billing, and licensing. Anyone who wants to access the Direct Web API must create a Trestle account at

Technology providers that already use Trestle can use their existing account to sign up for the Direct Web API as well. Using Trestle provides numerous benefits, including centralized data feed management, online licensing and document management, and one-stop shopping for a broad range of additional data products.


CoreLogic charges technology providers a fee to access the Direct Web API to cover the cost of ongoing API development, bandwidth, documentation, support, etc. Data license fees charged by the MLS may also apply. Visit for more information.


Imposed system limitations 1. API requests are being limited to Read and PATCH functions only. no POST operations will be allowed at this time. 2. Search ordering for replication is being limited to primary key and the resources Updated DateTime field. Requests containing ordering of other fields will be processes as ad-hoc search and will be limited to searches that narrow results to a reasonable limited set of data. This is configurable per matrix system but may have defaults for ad-hoc search set as under 2000 or 5000 records. 3. Security settings in each Matrix system retain the right to limit exposure to specific 'listing', 'member', 'office' (and other) tables and columns per application subscription. As such, all resources returned in the metadata requests are the resources and endpoints that reflect the current security groups access. 4. Queries will allow filtering on a limited set of fields set by each system, Any fields that do not allow filtering will be noted in the metadata annotations. These will always include the primary key and the update timestamp field. 5. String comparator searches will be limited to direct string matches, excluding substring searches like 'startswith(...)' and "endswith(....)"

Usage - Reading

Metadata for direct WebAPI access in Matrix systems - It's crucial to fetch a system's Metadata first in order to map out requests to the resources being exposed in the system. - Metadata requests use the standard ODATA format, and this will be the roadmap needed to make requests of the exposed data. Metadata requests follow the same pattern in all systems: {{MatrixHost}}/MatrixWebApi/Local/$metadata - "Direct" data means MLS systems not based on the RESO Data Dictionary can have differences in their resource naming and join structures. This means the examples used in this documentation may have table/resource names that are different than the system you are connecting to. This includes differences in available table names, named "actions," and even field name differences within tables. - The MetaData is returned as structured XML with a <Schema> section for each resource found under the same parent section node "<edmx:DataServices>" - Metadata resource format examples:

Description Example
The base resources are in the '<EntityType>' tags.
"RESI" is the table name in this example.
<EntityType Name="RESI">....
The resource column names are in the '<Property>' tags.
"Address" is a column name with a data type of string in this example.
<Property Name="Address" Type="Edm.String" />
Available joins are depicted within the '<NavigationProperty>' tags. <NavigationProperty Name="SA" Type="MatrixData.Agent.AGENT">
    <ReferentialConstraint Property="Matrix_Unique_ID" ReferencedProperty="SellingAgent_MUI" />
  • Expect available resource definitions to have the following metadata detail including a keyfield definition in the '' tag, followed by more properties and possibly actions: <Schema Namespace="MatrixData.Property" xmlns="">     <EntityType Name="Property">         <Key>             <PropertyRef Name="ListingKeyNumeric" />
            </Key> ...

Additional Field Metadata for direct WebAPI access in Matrix systems The direct WebAPI also has a Field endpoint for gathering additional metadata that cannot be adequately captured using the standard OData metadata endpoint. This endpoint can be found using the following path: {{MatrixHost}}/MatrixWebApi/Local/Field |Field Property|Description| |--|--| |FieldName|The system name used to reference the field in queries.| |DisplayName|A friendly, readable name for the field.| |SourceResource|The entity to which this field belongs.| |Orderable|Boolean. Can this field be used to sort a query?| |Queryable|Boolean. Can this field be used to filter a query?| |Editable|Boolean. Can this field be altered using the Patch method?| Note - Information displayed by the Field endpoint is based upon the permissions of the user calling the endpoint and may differ between different users with different permissions.

Define batching support and usage

The batching or "paging" process in ODATA defines the maximum number of returned records per request.

Any requested data will be returned with an imposed maximum row count. This is the maximum batch size.

Individual Matrix systems can impose different maximum batch sizes (the default is 1000) and requests can be made to receive smaller batches if desired. This is done with the request parameter, "$maxPageSize"



Returned sets that exceed the allowed number of rows per batch will include a 'nextLink' parameter with a URL. Call the URL to continue fetching the remaining data until the set is complete and no more 'nextLink' tags are included.


        {{MatrixHost}}/MatrixWebApi/Local/Property?$filter=ListingKeyNumeric ge 0

The equivalent link above will return a batch (or "page") of listings from the 'property' table up to the maximum number of records allowed by the system. The returned set will be ordered by its primary key 'ListingKeyNumeric' and contain a 'nextLink' parameter. The 'nextLink' parameter includes the information needed to continue from where the current batch ended. Repeating the request from each 'nextLink' in the returned batch repeats this process until the last record is reached.

Data replication process

Table replication involves (1) making an initial request for all records contained in a table, followed by (2) future requests for any updated data using 'LastUpdateDatetime.' This process retrieves a complete baseline copy of the table and then keeps it up to date via regular requests that only contain records that have changed since the last update. The replication processes requires the request to contain a defined $orderby parameter and it being set to the primary key or the entities UpdateTimestamp (see metadata for your resource) It also requires either no select clause or a select clause that includes both of these fields.

    Example (step 1 of 2):

        {{MatrixHost}}/MatrixWebApi/Local/Replication/Property?$orderby=ListingKeyNumeric&$count=true&$filter=ListingKeyNumeric gt 1 and ModificationTimestamp gt 1900-01-01T10:00:00.100-04:00

The link above will return a batch (or "page") of listings from the 'property' table up to the maximum number of records allowed by the system. The returned set will be ordered by its primary key 'ListingKeyNumeric' and may contain a 'nextLink' parameter. The 'nextLink' parameter includes the information needed to continue from where the current batch ended. Repeating the request from each 'nextLink' in the returned batch repeats this process until the last record is reached.

After completing baseline replication for a table, further calls need to use the 'LastUpdateDatetime' filter to only retrieve records that are new or changed since the last update.

    Example (step 2 of 2):

        {{MatrixHost}}/MatrixWebApi/Local/Replication/Property?$filter=LastUpdateDatetime ge 2022-01-01T12:59:33.223-06:00

The equivalent links above will return a batch (or "page") of listings from the 'property' table up to the maximum number of records allowed by the system. The returned set will be ordered by its update timestamp 'LastUpdateDatetime' and its primary key 'ListingKeyNumeric'. The returned data may contain a 'nextLink' parameter as described above.

Note: if desired, replication can be done with limited columns by calling with a 'select' clause.


        {{MatrixHost}}/MatrixWebApi/Local/Replication/Property?$orderby=ModificationTimestamp&$filter=ListingKeyNumeric ge 0&$select=ListingKeyNumeric, ModificationTimestamp

Supported call URI structures with examples

  • URI patters supported
Description Example
Direct resource requests. requesting the complete table with all associated join data {{MatrixHost}}/MatrixWebApi/Local/Property?
Specific resource requests. requesting a single specific row from the 'property' table with all associated join data. {{MatrixHost}}/MatrixWebApi/Local/Property({PrimaryKeyValue})
Direct column select. The complete property table with only the one selected field. {{MatrixHost}}/MatrixWebApi/Local/Property?$select=ListingKeyNumeric
requesting media index between 3 and 6 belonging to owning records of the media(properties) in primary key range of (13497 to 2205900) {{MatrixHost}}/MatrixWebApi/Local/media?$filter=ResourceRecordKeyNumeric ge 13497
and ResourceRecordKeyNumeric le 2205900
and MediaType eq 'IMAGE' and Order ge 3 and Order lt 6
fetch all media from a specific property {{MatrixHost}}/MatrixWebApi/Local/Property(123456)/Media?

Supported filter options

Option Example
equal filter=ListingKeyNumeric eq 610011
equal (string) filter=FirstName eq 'Mike'
not equal filter=ListingKeyNumeric ne 610011
multiple comparators filter=ListingKeyNumeric eq 6100 or ListingKeyNumeric gt 400000
less than filter=ListingKeyNumeric lt 610011
less than or equal filter=ListingKeyNumeric le 610011
greater than filter=ListingKeyNumeric gt 610011
greater than or equal filter=ListingKeyNumeric ge 610011
greater than (timestamp) filter=LastChangeTimestamp gt 2010-01-08T09:54:57.08-05:00

Usage - Editing

The direct WebAPI supports the use of Patch to modify certain properties of entities. Before attempting to alter the data for an entity, please refer to the Field endpoint mentioned above to ensure the properties you wish to alter at Editable.

Example Using a Patch call to change the list price on a property Method: Patch URL: {{MatrixHost}}/MatrixWebApi/Local/Property(123456) Body: { "ListPrice": 350000.00 } Common Return Messages When calling patch methods, it can be common to bump against imposed rules that have been put in place by administrators that help to ensure the data remains stable and useful. When one or more of these rules is broken by a patch command, a message will be sent back containing information about the problem.

400 - A rule was broken and the patch command was not successful. 200 - A warning message was raised, but the patch command completed successfully.