Webflow vs Framer for a listings site: the write path decides it
For a site whose content is a feed, neither the design tool nor the item ceiling decides it. What decides it is how listings get in, who owns the key that puts them there, and what happens when the sync dies halfway.
A listings site is not a marketing site with more pages on it. Its content arrives from somewhere else, changes without anyone opening the editor, and is worth nothing the moment it goes stale. That moves the decision away from the design tool and away from the item ceiling, and onto a narrower question: how do listings get in, and what happens the night that stops working.
The general ceiling comparison is worth reading first, because it settles the numbers and corrects a claim that most comparisons still repeat: see Webflow CMS vs Framer CMS. This post picks up where that one stops, at the point where the content is a feed rather than a set of pages.
First check whether the CMS is involved at all
On US residential real estate the listings usually come from an MLS through IDX, and an IDX product renders them itself. iHomeFinder, IDX Broker and Realtyna each ship their own search, their own detail pages and their own lead capture. The CMS holds pages about the agent, not the listings. If that is the shape of the project then this comparison decides nothing, and the questions that matter are how each platform handles a third-party embed and where the lead goes afterwards. We have written both halves up: IDX on Webflow and the iHomeFinder setup, alongside the wider real estate work.
The CMS only decides when you own the data. Rentals you manage yourself, a developer's own inventory, a directory, commercial space, or any market where no MLS feed exists. That is the case this post is about, and it is also the case where a gated area for saved searches starts to matter.
The ceilings run the opposite way to the reputation
Framer publishes a higher item ceiling than Webflow. With add-ons on Pro it reaches 40,000 items and 40 collections; Webflow's Business plan with add-ons reaches 20,000. Both figures are the vendor's own, read on 4 September 2026, and both are set out in full in the Webflow limits reference and the Framer one. The reputation runs the other way round, which is worth knowing before someone rules Framer out in a kickoff call.
It rarely binds anyway. Twenty thousand is a lot of listings, and a portfolio that large has usually outgrown a website builder for reasons that have nothing to do with counting. The ceiling is the wrong axis. The write path is the right one.
How listings actually get in
| Question | Webflow | Framer |
|---|---|---|
| Server-side write path | Data API, generally available | Server API, open beta since 12 Feb 2026 |
| Items per request | 100 | Not published |
| Requests per minute | 60 on Starter and Basic, 120 on CMS, eCommerce and Business | Not published |
| Publish on write | Create Live Items publishes on creation | Publishing is a separate call |
| Site publish rate | One successful publish per minute | Not published |
| Credential scope | Site token, created per site | API key bound to one project |
The second and third rows are the ones that decide a nightly rebuild. Twenty thousand listings at 100 items a request is 200 requests, and at 120 a minute that is under two minutes of request time. Whether a full refresh is reasonable or out of the question turns on those two numbers, and a comparison written about the design tool never reaches them.
On the Framer side those cells are empty because the vendor has not filled them. The Server API does the job: it exists to update and publish a project from any server without opening the project from a client, and syncing an external database into the CMS is the first use case it names. What is missing is the operational envelope, and an envelope you cannot read is one you find out about in production.
Who owns the key after the agency leaves
A Webflow site token is generated in site settings under Apps and integrations, only by a site administrator, and Webflow's own guidance is to revoke an administrator's token when they leave. The token belongs to the site. A Framer API key is different by design: the documentation says the keys authenticate your script as the user who created them, and are bound to a specific project. So the sync runs as a person. On an agency build that is a real handover question, because the script keeps working exactly as long as that account does, and nothing on the site says which account it is. Write it down at build time, in the same place as the DNS and the repository, or the first person to leave takes the listings feed with them.
One practical note from building on it. The Server API documentation says the key is generated in the General section of Site Settings. On the project we built, keys were made through the command palette instead, open settings and then API Keys. Allow for the docs and the product to disagree on that one.
What a page is allowed to render
Webflow publishes per-page limits and updated them recently. Read on 4 September 2026: up to 40 Collection lists per page, up to 10 nested Collection lists per page, 100 items per Collection list without pagination, and 100 items per nested Collection list. For a listings grid with agent cards inside it, those four numbers are the whole design brief.
Two things follow. The figure of five items in a nested list, which comparison content still repeats, is stale, so a layout that was rejected on that basis is worth revisiting. And Framer publishes no equivalent page: its help article on limiting visible items explains where the control lives and names no maximum, which for a page rendering a large result set is a gap you close by testing rather than by reading.
What breaks halfway
Nothing in either write path is transactional. On the Framer Server API we have watched a script die mid-run and leave the project half-updated with no way to roll the rest back, so a sync has to be written to be safely re-runnable rather than to succeed once. Webflow's failure mode is narrower for a simple reason: its Data API touches CMS items and nothing else, while the Server API can also move the canvas and the project settings, so a bad run there can change the design as well as the data. Either way the rule is the same. Make the script idempotent, key every item on the feed's own id, and never let correctness depend on a run reaching the end.
So which one
- Listings come from an MLS through IDX: this is not the comparison to make. Compare embed handling and lead routing instead.
- You own the data and it syncs from a server every night: Webflow, on the published operational envelope alone.
- The catalogue is genuinely enormous and changes rarely: Framer has the higher ceiling of the two.
- Someone updates listings by hand in the editor: either will do, and the design tool decides it after all.
None of this is permanent. Both vendors are moving, the Server API is still in open beta, and the gaps in its documentation are exactly the kind that close. Date the table, keep the source links, and check them again before the next build starts rather than trusting a comparison written a year ago, this one included.
