How MLS Data Becomes a Video

A new listing lands in the MLS, and somewhere between “this property exists” and “there’s a video of it on Instagram,” a specific sequence of steps has to happen. For most agents today, that sequence is manual, which is exactly why most listings never get a video at all. This is a breakdown of how that pipeline is actually built. What’s deterministic rule-based logic, and what’s genuinely AI, matters if you’re evaluating whether to build this yourself or hire it out.

This isn’t a marketing page for a video tool. It’s a teardown of the mechanism, written for agents, brokers, and marketing managers who want to understand the pipeline before they commit to building or buying it.

What’s Actually in an MLS Feed

An MLS listing isn’t just a webpage. It’s structured data, and that’s what makes automation possible in the first place. A typical feed exposes the address, list price, bedroom and bathroom counts, square footage, an ordered array of listing photos, the agent’s written remarks, and a status field (active, pending, sold).

Two data-access standards dominate how agents and vendors actually pull this data. RESO Web API is the newer standard, a RESTful, OData-based API that most MLS systems have migrated to or are actively migrating toward, because it standardizes field names across different MLS providers in a way the older system never did. RETS (Real Estate Transaction Standard) is the older protocol, still running in a meaningful number of regional MLS systems, and it works differently enough — different authentication flow, different query syntax — that a pipeline built for one doesn’t automatically work for the other. Anyone building this needs to confirm which standard a given MLS actually supports before assuming compatibility.

Step 1: Detecting a New or Updated Listing

The pipeline needs to know the moment a listing goes live or changes status, without a human checking a dashboard. Most implementations poll the feed on a short interval, every 10 to 15 minutes is common, filtering for listings with a ModificationTimestamp after the last successful check. A smaller number of MLS systems support webhook-style change notifications, which is faster but less universally available.

The distinction between “new” and “updated” matters for what happens downstream: a brand-new listing triggers the full video-generation pipeline, while a status change (say, a price drop) might only trigger a lighter-weight update post rather than a full new video, depending on how the workflow is scoped.

Step 2: Preparing the Photo Assets

Photos arrive as an array, usually already in the order the agent uploaded them. That’s not necessarily the order that makes the best video. A sorting pass typically promotes the strongest exterior or hero interior shot to the front, using whatever signal is available (sometimes a PrimaryPhoto flag the MLS itself provides, sometimes a simple heuristic based on image dimensions and position).

Before any photo gets used, it runs through a validation pass: a minimum resolution check (low-res thumbnails make for a visibly bad video), and a filter for duplicate or near-duplicate frames, which happen more often than you’d expect when an agent uploads the same shot twice from slightly different angles. A listing that fails this validation, too few usable photos, resolution too low, gets flagged for manual review instead of producing a video nobody would want posted.

Step 3: Generating Overlays and Captions

This is the step where the pipeline splits cleanly into rule-based and AI-assisted work, and it’s worth being precise about which is which. Pulling the price, bed/bath count, square footage, and address into on-screen text overlays is deterministic field-mapping. There’s no judgment call in taking a number from a feed and putting it on screen, so this stays rule-based.

Drafting the social caption is different. The agent’s written remarks are free text, often full of real-estate shorthand and incomplete sentences, and turning that into a clean, platform-appropriate caption is a writing task, not a lookup. This is where an AI step genuinely earns its place. A language model reads the remarks field and drafts a caption variant, which can be queued for a quick human glance before posting or sent straight through, depending on how much the agent trusts the output after reviewing a batch of early examples.

Step 4: Assembling the Video

The validated, ordered photos get sequenced into a short vertical video. 9:16 aspect ratio is the deliberate choice here, because that’s the native shape for Instagram Reels, TikTok, and YouTube Shorts, and a horizontal video gets cropped or letterboxed on all three. Fifteen to thirty seconds is the typical duration: long enough to show 5-8 photos with a brief hold on each, short enough that it doesn’t ask for more attention than a scrolling viewer will give a listing they haven’t decided to care about yet.

Each photo gets a short transition into the next, the pre-generated text overlays get burned into the relevant frames, and a branded end-card closes the video: agent name, logo, and contact information, generated once per agent or brokerage and reused across every listing. In parallel, the same validated photo set gets assembled into a static image-carousel post, since not every platform rewards video the same way a feed-based carousel performs on an audience that scrolls through photos more comfortably than it watches a video to completion.

Step 5: Distribution

Finished assets get queued to the agent’s or brokerage’s social accounts through each platform’s publishing API. Instagram and Facebook both support scheduled or immediate publishing this way, and TikTok’s API has moved in the same direction, though with its own quirks. This step has a maintenance reality worth being upfront about: platform access tokens expire periodically and need re-authorization, so a pipeline left completely unattended will eventually silently stop posting until someone notices and refreshes the connection. Any team running this long-term should expect it as a recurring, if infrequent, maintenance task — not a one-time setup.

What This Doesn’t Replace

None of this replaces a photographer. The entire pipeline starts from whatever photos already exist in the MLS listing. If those photos are poor, the output video will be too, just automated instead of manually assembled. What this automates is everything downstream of the photos: the sorting, the validation, the overlay generation, the caption drafting, the video assembly, and the posting. For an agent who’s currently skipping video entirely because there’s no time to manually edit every listing, that’s still the entire gap this closes.

If you’re evaluating whether to build this yourself or have it built, the honest answer is that the mechanism isn’t complicated. It’s the accumulation of small, correct steps (feed polling, photo validation, overlay logic, publishing-API maintenance) that makes it worth automating rather than doing by hand once, and then never again.

Why Most Attempts at This Stall Out

Teams that try to build a version of this themselves usually get the video-assembly step working first, because it’s the most visible and the most fun to prototype. Stitch some photos together, add text, done. What actually causes these projects to stall isn’t the video logic. It’s the two unglamorous pieces on either end: reliably detecting new listings without missing any or duplicating work, and keeping the social publishing connection alive over months without someone noticing it quietly broke.

Feed polling sounds trivial until you account for the actual failure modes. A listing can appear in the feed, get pulled seconds later for a data error on the MLS side, and reappear with a different ID. A naive “check every 15 minutes for new listings” script will sometimes process the same listing twice, or miss one entirely if the polling window and the listing’s active window don’t overlap cleanly. A production version of this tracks processed listing IDs explicitly and treats re-appearance as a known case to handle, not an edge case to ignore.

The publishing side has a different failure mode: it works perfectly for weeks, then silently stops, because a platform’s access token expired and nothing in the pipeline was watching for that specific failure. The fix isn’t complicated. A scheduled check that verifies the connection is still live, with an alert if it isn’t, but it’s the kind of maintenance work that’s easy to skip when you’re focused on getting the first version shipped, and expensive to discover is missing three months later when an agent asks why nothing has posted in two weeks.

What a Reasonable First Version Looks Like

A first version doesn’t need every edge case solved on day one. It needs: reliable new-listing detection with duplicate protection, a basic photo validation pass (resolution and count, nothing fancier), one video template rather than several variants, and a manual review step before anything auto-posts, while the team builds confidence in the output. The caption-drafting AI step and full auto-publishing can come once the earlier stages have proven themselves on a few dozen real listings — there’s no requirement to launch with every piece running unattended from day one.

How Long Each Step Actually Takes

It’s worth being specific about where the time actually goes in production, since “automated” doesn’t mean “instant” at every stage. Feed polling and field extraction happen in well under a second once a listing is detected — this is a straightforward API call and a data-mapping operation, nothing computationally heavy. Photo validation adds a few more seconds per listing depending on how many images need resolution checks and duplicate comparison.

The AI-assisted caption draft is the one step with real latency, typically a few seconds per request depending on the model and how much of the agent remarks field there is to work with — this is still fast in absolute terms, but it’s the slowest individual step in the pipeline by a meaningful margin, simply because it involves an actual language-model call rather than a database lookup. Video assembly itself — sequencing photos, applying overlays, rendering the final file — is usually the second-slowest step, taking anywhere from several seconds to roughly a minute depending on resolution and length, which is why “under a minute” end-to-end for steps 3 and 4 combined is a reasonable target rather than an exaggeration.

None of this needs to happen in real time from the buyer’s perspective. A listing going live and its video appearing on Instagram ten or fifteen minutes later is a perfectly reasonable outcome — nobody’s expecting the video within the first thirty seconds, and building for near-real-time latency when it isn’t actually needed just adds engineering complexity without a real benefit.

Where This Fits Relative to Off-the-Shelf Tools

There are a growing number of AI video tools that can turn a batch of photos into a short video if you upload them manually. Those tools solve the video-assembly step reasonably well, which is genuinely useful if your actual bottleneck is “I don’t know how to edit video.” They don’t solve the detection step — someone still has to notice the new listing and start the process — and they don’t integrate with your MLS feed at all, because that’s not the problem they were built to solve. If your real bottleneck is remembering to start the process for every single listing, a better video editor doesn’t fix that; only removing the manual trigger does.

For the commercial version of this breakdown, including a self-check for whether your MLS feed is ready for this, see our MLS listing video automation page. For a worked example written in the same honest, mechanism-first style as this post, see the MLS listing video automation case study.

Further reading on the data standards referenced above: RESO Web API documentation and the RESO data dictionary.