• Real Estate Consulting Rooted in Real Experience

Posts By :

Brian Kinash

RESO Web API: What It Is, Why It Matters, and What Most People Get Wrong

 1024 683 Brian Kinash
By:
0

RESO Web API — What MLS Executives Need to Actually Understand

RESO — the Real Estate Standards Organization — is often referenced as if it’s a single thing.

It’s not.

RESO is an organization made up of multiple workgroups and standards, including:

  • The Data Dictionary (how real estate data is structured)
  • The Transport Workgroup (how data moves)
  • And the Web API (how systems actually access and exchange that data)

For MLS executives, it’s the Web API that matters most operationally.

Because it’s the point where standards stop being theoretical… and start affecting how your data is consumed by the outside world.

What the RESO Web API Actually Is

The RESO Web API is a standardized way for technology partners to access MLS data.

Historically, every integration required custom development — different structures, different rules, different endpoints.

The Web API changes that.

Built on OData, it provides a consistent framework for how data is requested, filtered, and returned — regardless of the MLS platform behind it.

In simple terms:

It’s the difference between every vendor building a custom connection… and everyone speaking the same language.

Why This Matters Now

This is no longer a future-state discussion.

Vendors are increasingly building their products assuming RESO Web API access.

Which means:

  • MLSs without a properly implemented API create friction for vendors
  • Integration timelines increase
  • Product capabilities become limited or inconsistent

Most modern MLS platforms now technically support the RESO Web API.

But “support” isn’t the same as “ready.”

The real work sits in:

  • Data Dictionary alignment
  • Field mapping consistency
  • API validation and certification
  • Ongoing governance of how data is exposed

Where MLSs Get Tripped Up

The most common mistake is treating RESO compliance as a checkbox.

Turn it on. Get certified. Move on.

In practice, that approach creates more problems than it solves.

Real compliance means:

  • Your data is consistently mapped to RESO standards
  • Field definitions are clear and aligned
  • The API behaves the way vendors expect it to behave

Because from the vendor’s perspective, they’re not integrating with your internal system.

They’re integrating with your API.

And if that API is inconsistent, incomplete, or loosely mapped… it shows immediately.

The Executive Takeaway

RESO isn’t just a standards conversation — it’s an operational one.

The Web API is now a core part of how your MLS participates in the broader technology ecosystem.

Getting it right isn’t about enabling a feature.

It’s about ensuring your data can be reliably understood, accessed, and used by the partners your members depend on.

If your MLS is working through RESO alignment, implementation, or validation — this is exactly where focused effort makes a measurable difference.

MLS Consolidation: What Gets Lost When Organizations Merge

 1024 683 Brian Kinash
By:
0

MLS consolidation has been accelerating across North America for years. The business case is straightforward — shared infrastructure, reduced costs, broader data coverage. But the execution is almost always harder than the rationale suggests, and the things that get lost in a merger are rarely the things anyone planned for.

The Data Migration Problem

Every MLS has years — sometimes decades — of listing history stored in a platform configured specifically for that organization. Field names differ. Lookup values differ. Status workflows differ. When two systems merge, someone has to make decisions about what maps to what, what gets left behind, and what historical data is worth migrating at all.

These decisions have long-term consequences. Incomplete historical data affects market reporting. Mapping errors create inaccuracies that persist for years. And members who relied on specific search configurations or hotsheet setups find that their workflows have quietly broken.

The Culture Problem

Data gets the most attention, but culture is often the harder challenge. MLSs have distinct member relationships, staff identities, and governance structures. Merging two organizations means navigating whose rules apply, whose board has authority, and whose members feel like they lost something.

The MLSs that handle this well invest in communication before, during, and after the transition — not just to staff, but to members. They explain why, they explain what changes, and they give people a clear place to go with questions and concerns.

What to Get Right Before You Merge

The best time to plan for a merger’s complexity is before the decision is finalized. That means auditing both organizations’ data structures, documenting member-facing workflows, identifying governance conflicts, and building a realistic transition timeline — one that accounts for the human side, not just the technical one.

If your organization is exploring or navigating a consolidation, let’s talk about what’s worth planning for now.

Choosing an MLS Platform: What the Sales Demo Won’t Tell You

 1024 683 Brian Kinash
By:
0

MLS Demos Look Great… Until They Don’t

Every MLS platform looks exceptional in a demo.

The interface is clean. The workflows make sense. The roadmap sounds aligned with everything you’ve been trying to solve.

And in most cases, none of that is misleading.

The problem is… the demo isn’t the job.

MLS platform decisions are some of the least frequent — and most consequential — decisions an organization will make.

They typically surface during moments of pressure:

  • Mergers and consolidations
  • Regional unification efforts
  • Or after years of accumulated friction with an existing system

Even then, full replacement is often avoided. Instead, MLSs layer on:

  • Front-end of choice strategies
  • Data synchronization between multiple systems

Both approaches introduce their own operational complexity — which only reinforces the reality:

You don’t get many chances to get this decision right.

Where the Demo Starts to Break Down

The purpose of a demo is to showcase capability.

The challenge is that MLSs don’t operate in controlled environments — they operate in edge cases, exceptions, and deeply ingrained workflows.

That gap tends to show up quickly.

Implementation vs. Presentation
What feels intuitive in a guided walkthrough often becomes a detailed, time-consuming configuration exercise once real data, rules, and member expectations are introduced. The difference between “it works” and “it works for us” is where timelines expand.

The ‘Almost Ready’ Feature
New modules are frequently introduced early — demonstrated confidently and positioned as near-term deliverables. In practice, they often arrive with incomplete documentation, evolving workflows, and implementation teams who are still learning the product themselves.

At that point, the MLS isn’t just implementing a feature — it’s helping stabilize it.

Support Reality
Support is rarely part of the demo experience, but it defines the long-term relationship. SLA targets matter less than actual resolution times, escalation clarity, and whether the support team understands MLS-specific context when something breaks.

The Questions That Surface Reality

Most MLSs ask good questions. Fewer ask the ones that reveal how the system actually performs under pressure.

  • What do resolution times look like for issues like ours — in practice, not on paper?
  • Which MLSs of our size have you onboarded recently — and can we choose who we speak to?
  • What on your roadmap is committed versus directional?
  • What has gone wrong in recent implementations, and how was it handled?

The answers matter — but so does how they’re delivered.

Specificity, confidence, and transparency tend to be more telling than the response itself.

Reference Checks: Moving Past Polite Conversations

Reference calls are one of the few places where operational truth is accessible — if you ask the right questions.

  • How long did your migration actually take?
  • What surprised you once you were live?
  • What’s your biggest ongoing frustration?
  • If you were starting over, what would you do differently?

You’re not looking for reassurance.

You’re looking for friction — because that’s where the real experience lives.

Configuration Is Where the Decision Becomes Real

Every MLS operates with its own data structures, rules, and expectations.

The critical question isn’t whether a system can do something.

It’s whether it can do it in a way that aligns with how your MLS actually operates.

There’s a meaningful difference between:

  • “Yes, that’s supported”
  • And “Here’s exactly how we configure and maintain that in production”

Before committing, walk through real workflows with the implementation team — not just sales — and get those answers in writing.

This is where most surprises are either uncovered… or deferred.

Final Thought

Most MLS platform challenges don’t stem from fundamentally bad systems.

They come from a gap between what was presented during the demo and what it takes to operate the platform day-to-day.

Closing that gap is the real work — and the difference between a successful transition and a prolonged struggle.

If you’re evaluating a platform, navigating a merger, or considering new modules, this is the stage where clarity matters most.

Because once you move beyond the demo, you’re into decisions that are very difficult to unwind.