API, Feeds & Integrations is the MLS RealtyHub connectivity area for businesses that need real estate data to work beyond a single platform interface. It supports programmatic access, structured outbound feeds, Data as a Service, integrations with external systems and project-based migration, so agencies, developers, data companies and technology teams can connect MLS RealtyHub to an existing technical environment or build the required data flow around a new one. The value is not simply “having an API”; it is choosing the right method for how data needs to be accessed, delivered, connected or transferred.
Your Existing Technology Is the Starting Point
A company adopting MLS RealtyHub may already operate a CRM, website, property portal, internal database or analytics environment. Replacing those systems solely to gain access to another source of real estate information may create more operational work rather than less. Manual exports, repeated data entry and incompatible transfer processes become especially difficult when information needs to participate in several systems at the same time.
MLS RealtyHub is designed to fit into that wider environment through different connectivity options. Business decision-makers can define how the platform should fit into the existing stack, while technical teams determine which supported access or integration model matches the requirement. The same area also supports companies that need structured data access without a conventional CRM or portal, as well as clients moving existing information during a technology transition.
Start With What Needs to Happen to the Data
Choosing between an API, feed, DaaS arrangement, Integration or Data Migration Service should begin with the business requirement rather than the technology name. A company that needs a one-time database transfer has a different problem from a company that needs Listings delivered repeatedly to another environment, and both differ from a client that needs two specific systems connected.
A useful decision starts by establishing five things:
- what information is involved, such as Listings, Projects or a supported Data Product;
- where that information needs to be used, including an existing CRM, portal, website, database or analytical environment;
- whether the need is one-time or recurring;
- whether standard access or delivery is enough, or a system-specific Integration needs to be scoped;
- what technical and commercial conditions require separate confirmation for the selected connection.
This approach keeps the product choice tied to an operational need. It also prevents different entities from being collapsed into the generic idea of “integration”, which can hide important differences in responsibility, delivery model and implementation scope.
API Access and Feed Delivery Solve Different Jobs
MLS RealtyHub API
The MLS RealtyHub API provides a programmatic way for another technical environment to work with supported platform resources. Its resource scope includes Listings, Projects and Data Products. The existence of an API does not mean every platform entity is automatically exposed as an API resource.
Endpoints, authentication, schemas, request formats, rate limits and error handling depend on the applicable API specification.
API-Lite Keeps the Scope Narrower
API-Lite is a lighter programmatic access option focused specifically on Listings. It can be relevant when the requirement is property-focused and does not need the broader resource scope of the main API.
Its narrower Listing-only scope is the key distinction from the full API.
JSON and XML Feeds Deliver Organised Property Data
Property feeds address a different type of requirement: organised outbound delivery of property data. MLS RealtyHub supports JSON and XML as feed formats, allowing property information to be supplied in a structured form for use in an external environment.
JSON and XML are delivery formats rather than two separate business capabilities. The exact schedule, field structure, transport method and destination depend on the relevant feed specification, so the existence of a feed does not guarantee a particular update frequency or delivery behaviour.
DaaS Makes Access to the Data the Product
Real Estate Data as a Service changes the focus. Instead of starting with a specific external system that needs to be connected, the client starts with a requirement for structured real estate data. The value is therefore the data-access proposition itself, while the delivery mechanism can vary according to the dataset, commercial scope and supported access method.
At this level, DaaS can support several access and delivery modes:
- UI-based access;
- data exports;
- API access;
- structured data feeds;
- custom delivery arrangements;
- subscription-based access.
These options describe the available DaaS model at product-area level, but not every dataset is available through every method. Dataset coverage, access conditions, delivery frequency and commercial packaging depend on the specific Data Product being used.
A Real Integration Starts With Two Real Systems
An Integration is more specific than an API. It represents a supported connection between MLS RealtyHub and another system or channel, which means the external environment matters as much as the MLS RealtyHub capability. The connection has to be understood in the context of what information the client needs to exchange and what the other system can support.
CRM Integration and Property Portal Integration are therefore positioned as available by request, not as universal plug-and-play connectors. A company can discuss a connection between MLS RealtyHub and its CRM or portal, but this does not establish automatic compatibility with every product on the market. The technical scope, data direction and implementation requirements depend on the actual systems involved.
Property Portal Integration Is Only the Technical Layer
Connecting MLS RealtyHub technically with a property portal and managing the wider business process of distributing Listings are related activities, but they are not the same capability. Property Portal Integration covers the technical connection required for supported data exchange with a portal.
Publication strategy, Listing distribution and broader syndication workflows belong to the dedicated marketing and distribution area of MLS RealtyHub. Keeping that separation matters because a technical connection should not automatically be interpreted as confirmation that every Listing is distributed to every portal or that publication conditions are identical across destinations.
Migration Is About Moving From One State to Another
Data Migration Handles the Transition
A business changing systems may already have property records, media or other existing data that cannot simply be abandoned. Data Migration Service covers the project-based work required to transfer agreed client information as part of that transition. The starting point is the existing data environment; the result is the completion of the transfer within the scope agreed for the migration project.
Because migration involves implementation work, it is treated as a Service rather than as an automated data-access interface. The exact source format, deliverables, timing and project conditions depend on the agreed migration scope rather than on a universal migration template.
Recurring Exchange Begins After the One-Time Transfer
If information needs to continue moving after the initial transition, the requirement changes. Ongoing exchange belongs to an API, feed or Integration model designed for recurring connectivity rather than to Data Migration itself.
This distinction prevents a common expectation problem. Completing a migration does not mean two systems will continue synchronising indefinitely, and an ongoing Integration should not be described as migration simply because data passes between environments.
Two Businesses Can Need Completely Different Connectivity
A company with an established technology stack might already know exactly where MLS RealtyHub data needs to go. Its technical team can define the required information, select the appropriate API, feed, DaaS or Integration approach and incorporate that connection into the existing environment. MLS RealtyHub becomes an additional data and connectivity layer rather than a replacement for every tool the company already operates.
Another client may have the business requirement but lack the website, database, CRM or technical workflow needed to support it. In that situation, broader technical work may need to be scoped separately before the required connection becomes useful. MLS RealtyHub can participate in that wider solution, but connectivity does not include unlimited custom software. Full website development, white-label deployment and other broader implementations retain their own product and commercial scopes.
Different Participants Control Different Parts of the Process
A successful connection depends on more than the technology transferring information. The business has to define what it needs, the external environment has its own requirements, MLS RealtyHub provides the access or delivery mechanism, and implementation work may require a technical team. Making those roles clear prevents automation from being confused with business ownership.
Responsibility is generally divided across four areas:
- the client defines the business objective, required data and existing technical environment;
- the client or its technical team provides external-system requirements where a specific Integration is needed;
- MLS RealtyHub provides the access, delivery or connectivity mechanism within the scope of the selected capability;
- implementation work is scoped separately when migration, custom Integration or broader technical support is required.
The output therefore depends on the selected model. It may be programmatic access, an organised property feed, a supported system connection, access to a Data Product or a completed project-based migration. Those outputs should remain separate because each represents a different relationship between the client, its data and the surrounding technology.
The Connectivity Layer Has Clear Boundaries
API, Feeds & Integrations has defined technical and commercial boundaries. The details vary by capability and the selected implementation scope.
MLS RealtyHub does not provide:
- ready-made connectivity with every CRM, portal or external platform;
- universal two-way synchronisation across connected systems;
- guaranteed real-time or zero-latency exchange;
- undocumented API resources, endpoints, schemas or authentication methods;
- identical field coverage and delivery frequency across all feeds;
- permanent synchronisation as part of Data Migration;
- automatic availability of every DaaS dataset through every access mode.
These boundaries are part of choosing the right connectivity approach. They allow a business buyer to understand what MLS RealtyHub can support while recognising that technical specifications, connector-specific behaviour and commercial conditions depend on the selected capability and implementation scope.
Build the Right Connection Around Your Existing Stack
Your integration should start with the systems and data your business actually uses, not with a predefined technical package. Discuss your current stack, the information you need to exchange and whether the requirement is programmatic access, recurring delivery, a specific Integration or a data migration project.