Overview

Most applications need to hold MLS data briefly in order to function. That is not the same thing as storing a copy of the feed, or what's more commonly called data replication. This article explains where the line generally sits.

This is a general guideline, not a licensing determination. It exists to help you distinguish between the caching your application technically requires to perform well and the replication of MLS data, which is governed separately. For edge cases, the MLS is the final authority — their rules, your data license, and your MLS agreement override anything here. Reach out to us and we'll help you make the distinction.

Caching that is generally acceptable

Short-term caching in service of the requests your application is actively serving — holding data only long enough to render results, support pagination, or avoid re-requesting the same records while they are still in active use. A shared cache that serves many visitors is fine; what matters is how long the data lives and what it is there for, not how many people it is being served to.

The common thread: the data is transient, it exists to support live traffic against the API, and it is released once it is no longer needed for that.

What crosses into replication

Storing MLS data beyond the interaction that fetched it — persisting records so they can be queried, indexed, analyzed, or served independently of a live request, retaining them after they change or leave the feed, or treating your own store rather than the API as the source of truth.

The common thread: the data outlives the user's request and becomes an asset your application holds in its own right.

Repliers is built specifically to eliminate the need for replication. The API is designed to serve the queries an application would otherwise build its own datastore to answer, so in most cases the architectural reason to replicate simply doesn't arise.

If you believe your use case still requires it, we can look at the specifics and confirm whether replication is actually necessary — more often than not there is an API-side approach that covers the requirement.

What replication brings with it

Teams that go down this path take on a set of problems that do not exist when the application calls the API live. Worth weighing before you commit:

• ETL. You now own a pipeline: initial backfill, incremental syncs, retry and failure handling, schema changes on the MLS side, and monitoring for all of it. That is ongoing engineering cost, not a one-time build.
• Data freshness. Your copy is only as current as your last successful sync. Every gap is a window in which you are showing listings that no longer match the feed, and stale listings are a compliance problem regardless of cause.
• Licensing to copy. Being licensed to display the data is not the same as being licensed to store it. Replication generally requires its own approval.

And the questions to answer honestly before any of the above is worth taking on:

• Do I actually have to replicate, or does the API already answer the queries I need?
• Is this a genuinely proprietary use case, or a standard one I am solving in a non-standard way?
• What does a local copy do for me that a live query does not?

"How long is short-term?"

We do not publish a number, and this is deliberate. The purpose of this guidance is to set general expectations, not to impose precise architectural constraints on every application — caching needs differ too much between use cases for a single TTL to be meaningful.

The standard is functional, not numeric: cache should be cleared as soon as it is no longer needed for the request or session that created it.

That said, the lack of a fixed number isn't meant as an open door, or a loophole for replicating data. A cache that never expires functions as a stored copy of the data, and would be assessed on that basis. If you're considering a retention window longer than your application actually needs, bring it to us before you build it in.

Two things that always apply

1. Cached data must reflect the current state of the feed. Status changes, price changes, and removals must propagate. Stale listings shown to consumers are a compliance problem regardless of how the data got there.
2. Cached data must not be exported, resold, or exposed through your own API, bulk endpoint, or data feed.

When to ask

If your use case does not fit cleanly on either side of this line, start with us. We can review your architecture and confirm whether what you are describing is caching or replication, and whether the API already covers it. That usually resolves the question on its own. While the MLS remains the final authority we're here to help guide you in taking the best decision.

Updated on: 27/08/2026