An agent changes a property status in MLS RealtyHub. The change matters outside the platform, but a person may still have to notice it, copy the context, and notify another team or system. Realtime Webhooks and Triggers provide an event-driven handoff: when a supported event occurs, MLS RealtyHub can pass a signal to a supported external workflow. The capability is live; its technical scope depends on the implementation.
A Signal at the Moment a Workflow Changes
A webhook trigger connects an event in one system with a reaction in another workflow. Instead of asking someone to check MLS RealtyHub repeatedly, the receiving workflow can respond when the agreed event occurs. This makes the handoff part of the process rather than a separate reminder.
Webhook triggers can transmit events and notifications. They do not mean that every MLS RealtyHub resource, action, or external system is supported. Available events, transmitted fields, delivery rules, and receiving actions depend on technical documentation and integration setup.
The People and Systems Involved
This capability serves two connected roles. The agent or operational user owns the business event, such as an approved status change. A developer or integration specialist defines how a supported external workflow should react, using the access and documentation provided for the implementation.
The basic flow has three participants:
- the MLS RealtyHub user who creates or confirms the change;
- MLS RealtyHub, which detects a supported trigger and sends the event signal;
- the supported external workflow, which handles that signal according to its configuration.
From a Property Update to the Next Action
Consider a simple business-level scenario. An agent reviews a property record and changes its status. If that status change is configured as a supported trigger, MLS RealtyHub sends a signal to another system. The receiving workflow can then perform the action defined for that integration.
The receiving action varies by implementation. The sequence is straightforward: a user confirms the business change, MLS RealtyHub passes the supported event, and the external workflow responds within its agreed setup.
Before the Trigger
The team identifies the event that matters and the workflow that needs to know about it. It also decides who is allowed to make the underlying change in MLS RealtyHub and who is responsible for checking the result outside the platform.
When the Event Occurs
The user completes the relevant action in MLS RealtyHub. For this example, it is a change of property status. The trigger then passes a signal to the supported external workflow. The event name, payload, and delivery behavior are defined during integration setup.
After Delivery
The receiving workflow handles the event according to the approved integration design. A webhook moves the signal between steps. It does not remove professional responsibility for the original data, the permissions behind it, or the decision that follows.
What the Trigger Removes From the Manual Sequence
Without an event-driven connection, a team may rely on a repeated handoff: notice a change, decide who needs it, send a message, and wait for the next person or system to act. Each additional handoff creates another place where the process can pause or lose context.
With a supported webhook workflow, the sequence becomes shorter:
- the relevant change is confirmed in MLS RealtyHub;
- the configured trigger produces an event signal;
- the external workflow receives the signal and follows its approved rule;
- the responsible person checks the resulting business action when review is required.
A Different Kind of Automation From AI Assistance
Realtime Webhooks and Triggers sit inside the AI and Workflow Automation module, but they are not an AI writing feature. The AI listing description workflow turns voice or form input into an English draft that a user reviews before publication. A webhook trigger follows a defined event and passes a signal to another workflow.
This distinction matters because the control points are different. AI assistance requires review of generated content. Event-driven automation requires a defined trigger, an approved receiving workflow, and a clear owner for the action that follows. Both reduce repetitive work, but neither transfers responsibility away from the professional using MLS RealtyHub.
What Must Be Confirmed Before Setup
The capability is Live, but implementation still requires a defined technical scope. Before treating a webhook as part of an operating process, the team should confirm:
- which MLS RealtyHub events are supported;
- what resource and fields may be included;
- whether the required direction of exchange is supported;
- how the receiving system gets access;
- how delivery, retries, limits, and failures are handled;
- which package, configuration, or technical approval is required.
These details are established for the specific integration. Endpoint names, authentication methods, schemas, sample payloads, rate limits, retry logic, latency, and service-level commitments should not be assumed from the capability name.
The Current Boundary for Leads and Inquiries
Outgoing lead or inquiry webhooks are not part of the established workflow described here. A new inquiry should therefore not be treated as an event that MLS RealtyHub automatically sends to an external system. When a new request arrives, the user receives a service message or email notification.
This boundary keeps two workflows separate. MLS RealtyHub can receive inquiries through implemented channels, and the platform team can review a custom integration request. These options do not establish a standard outgoing lead webhook, a universal connector, or unrestricted transfer of lead data.
Webhook, API, and Feed Serve Different Jobs
A webhook is useful when another workflow needs to react to a supported event. An API provides programmatic access for sending or receiving supported data. A data feed is an organised outbound delivery of data under an agreed update model. These mechanisms can be part of the same technical environment, but each has its own scope.
Choose the mechanism by the job to be done:
- use a webhook discussion for an event and a resulting reaction;
- use an API discussion for programmatic access to supported resources;
- use a feed discussion for organised outbound delivery;
- request an integration review when a specific external system and business process must be connected.
When This Capability Is a Good Fit
Realtime Webhooks and Triggers are relevant when a team can name a specific event, a specific receiving workflow, and a responsible owner for the next step. “Notify another process when an approved property status changes” is concrete enough to assess. “Automate everything between our systems” needs a more defined scope.
A useful implementation request should state the business event, the system that needs the signal, the intended response, the data boundary, and the review point. The technical team can then confirm what is supported and identify anything that requires a separate integration decision.
Discuss a Supported Webhook Workflow
Bring one event, one receiving system, and the action you want to follow. The MLS RealtyHub integration team can confirm the available technical documentation, access route, supported scope, and next implementation step.