Native Web API - Listing (Dynamic Data) Reference

Access native listings and other data directly

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

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

The Native Web API provides access to native 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 Native Web API to expose all of the unique data natively 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:

Native 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 Native Web API uses the OData protocol with OpenID Connect (OIDC) authentication to provide secure data access for a specific MLS member. Applications calling the Native 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 Native Web API uses Trestle by CoreLogic to manage user accounts, credentials, billing, and licensing. Anyone who wants to access the Native Web API must create a Trestle account at trestle.corelogic.com.

Technology providers that already use Trestle can use their existing account to sign up for the Native 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.

Cost

CoreLogic charges technology providers a fee to access the Native 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 trestle.corelogic.com for more information.

Imposed system limitations 1. API requests are being limited to Read functions only. no POST or PATCH operations will be allowed at this time. 2. Search ordering is being limited to primary key and resources Updated DateTime field, often referred to as the 'ModificationTimestamp' 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. Requests for media must request the full media table (all fields) or at a minimum when wanting the media path returned the request must include in the media table select all of the following fields: "MediaPath, Order, TableID, MediaType, ResourceRecordKeyNumeric" 5. 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. 6. String comparator searches will be limited to direct string matches excluding substring searches like 'startswith(...)' and "endswith(....)" 7. OData multilevel expand operations will not be supported. Single expand per request only. 8. MEDIA requests will serve default size media set in the MLS at this time.

Metadata for native 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 - "Native" 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, joins for expand calls, 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. "SA" can be used as an expand call from this "RESI" table to the SalesAgent 'AGENT' data table in this example. Note that the caller must also have access to the 'Agent' table in this example.	`<NavigationProperty Name="SA" Type="MatrixData.Agent.AGENT">` `<ReferentialConstraint Property="Matrix_Unique_ID" ReferencedProperty="SellingAgent_MUI" />` `</NavigationProperty>`

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="http://docs.oasis-open.org/odata/ns/edm"> <EntityType Name="Property"> <Key> <PropertyRef Name="ListingKeyNumeric" />
</Key> ...

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"

Example:

{{MatrixHost}}/matrixwebapi/LOCAL/PROPERTY?$maxPageSize=500

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.

Example:

{{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.

Example (step 1 of 2):

{{MatrixHost}}/matrixwebapi/LOCAL/PROPERTY()?$filter=ListingKeyNumeric ge 0

Or simply:

{{MatrixHost}}/matrixwebapi/LOCAL/PROPERTY

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 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/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.

Example:

{{MatrixHost}}/matrixwebapi/LOCAL/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()?` or `{{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})`
Main resource AND inline the expanded resource. the full media row associated with the Property table row.	`{{MatrixHost}}/matrixwebapi/LOCAL/PROPERTY({PrimaryKeyValue})?expand=MEDIA`
Direct column select. The complete property table with only the one selected field.	`{{MatrixHost}}/matrixwebapi/LOCAL/Property()?$SELECT=ListingKeyNumeric`
Mutil-filter on main resource with selected fields and inline expanded table with selected field	`{{MatrixHost}}/matrixwebapi/LOCAL/Property()?$filter=ListingKeyNumeric ge 1000` `and SourceSystemName eq 'FMLS'&$SELECT=ListingKeyNumeric,ListAgentKeyNumeric,` `listprice,listsource,MlsStatus,StreetNumber,StreetName` `&$EXPAND=MEDIA`
requesting all media from a property listing and some basic fields from the property	`{{MatrixHost}}/matrixwebapi/LOCAL/PROPERTY()?$filter=ListingKeyNumeric ge 10112 and ListingKeyNumeric lt 239482109&$select=ListingKeyNumeric, StreetNumber, StreetName,CurrentPrice,PhotosCount&$expand=media`
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