Umbraco

How to integrate Umbraco with Webflow

What is Umbraco? Umbraco is an open source .NET content management system that teams run on their own servers or on Umbraco Cloud, the vendor's managed hosting. Content lives in a hierarchical tree of nodes, a REST Content Delivery API exposes published content for headless reads, and a Management API drives the backoffice.

Umbraco and Webflow are both content management systems, which shapes everything below. No Umbraco app exists in the Webflow Apps Marketplace, neither vendor ships a connector for the other, and any page promising a turnkey Umbraco to Webflow integration is describing something that does not exist. What does exist is a set of jobs you can do with the two public APIs and some work of your own.

Three approaches cover almost every real project. Migration reads content out of Umbraco once and writes it into Webflow CMS collections, which is what most teams landing on this page actually want. Headless delivery keeps Umbraco as the editorial system and renders its published content on a Webflow page with client side fetches. API sync puts a service you own between Umbraco webhooks and the Webflow Data API when both systems have to stay populated.

Migrate Umbraco content into the Webflow CMS

Migration is the most common reason to put these two products in the same sentence, and both vendors now ship an MCP server, which changes how the work gets done. The Webflow MCP server lets an AI client read your site structure and then create collections, fields and items inside the Webflow CMS, running under the Webflow permissions and roles you already have. Two documented limits matter for a migration: it cannot create new localized CMS items, and it will not touch workspace access settings.

On the other side, the Umbraco Developer MCP server wraps the Management API and runs as a standalone Node application rather than an Umbraco plugin, started with npx @umbraco-cms/mcp-dev@latest and authenticated with an API user client id and secret. Umbraco's own documentation tells you not to point it at a production instance, so run it against a local or isolated copy of the site you are moving. With an agent on each side you can have document types read out and collection schemas drafted in an afternoon, which is the part of a migration that used to eat a week.

The schema decisions are still yours, because a tree does not become a set of flat collections on its own. Work through these before anything writes to a live site:

• Node hierarchy: Umbraco nests content under parent nodes and Webflow collections are flat, so decide which parent levels earn their own collection and which collapse into a reference field.
• Block editors: Block List and Block Grid values arrive as nested JSON, so either flatten them into a rich text field or split each block type into its own collection.
• Media: Umbraco media items carry their own node identifiers, so upload the files to Webflow first and map the resulting asset URLs into your item payloads.
• Culture variants: a variant per language has no equivalent inside one Webflow collection, and the MCP server cannot create localized items, so handle translations as a separate pass.
• URLs: Umbraco paths follow the node tree, so export the old paths during the read and rebuild them as redirects before the Webflow site goes live.

Without an agent the same migration is a script: read pages from the Delivery API, reshape each node, then create collection items and update them through the Data API before you call the publish endpoint. Batch the writes and check the current rate limits before you point a script at a few thousand nodes.

Render headless Umbraco content on a Webflow page

If Umbraco stays as the editorial system, a Webflow page can read its published content directly in the browser. The Delivery API is opt in rather than on by default, so it has to be enabled in configuration and registered in the application before any request works. Once it is live, content is served from /umbraco/delivery/api/v2/content with filtering, sorting and paging as query parameters, and Accept-Language selecting a culture variant.

Your Umbraco version decides whether this is available at all. Umbraco 18 is the current short term support release and Umbraco 17 the current long term support release, while Umbraco 13 leaves support in December 2026 and every other version below 17 is already past end of life, per Umbraco's support schedule. Umbraco Heartcore, the managed headless product, is still sold and adds a GraphQL endpoint, but you do not need it here, because the Delivery API ships with the open source CMS.

Drop the fetch into a Code Embed on the page that should show the content, and give the Umbraco host a CORS rule for your Webflow domain:

const res = await fetch(
  "https://cms.example.com/umbraco/delivery/api/v2/content" +
  "?filter=contentType:article&sort=updateDate:desc&take=10",
  { headers: { "Accept-Language": "en-US" } }
);
const { items } = await res.json();
document.querySelector("#posts").innerHTML = items
  .map(function (i) { return "<li>" + i.name + "</li>"; })
  .join("");

Be clear about what this costs you. Content pulled in this way never enters the Webflow CMS, so there is no Collection List to bind, no CMS page per item, no native SEO fields, and search engines see only what renders after the request resolves. The Api-Key header that exposes unpublished nodes belongs on a server, never in browser code, and genuinely protected content needs the OpenID Connect flow rather than a public fetch. Use this pattern for a feed or a listing, not for pages you want ranking.

Sync Umbraco and Webflow with the Data API

Keeping both systems populated needs a service you build and host, since neither platform can call the other on its own. Umbraco webhooks are configured under Settings > Webhooks with five events available by default, covering content published, unpublished and deleted plus media saved and deleted, and you can attach custom headers such as an authorization token to each one. Your endpoint receives that payload, reshapes it, and writes through the Webflow Data API.

Four things determine whether the service survives contact with real editors:

• Credentials on both sides: Webflow expects a bearer token while Umbraco expects its own keys, so store each in your service and rotate them on a schedule you control.
• Field mapping as data: keep the document type to collection map in configuration rather than in code, because editors will add fields long after the migration is finished.
• Loop prevention: a write into Webflow fires a Webflow webhook that can write back into Umbraco, so stamp each sync with an origin marker and drop anything you sent yourself.
• Retries with backoff: answer every incoming webhook immediately and queue the real work, then retry failed writes with increasing delays so a rate limit does not lose an edit.

None of that is exotic, but it is a service with an owner and an on call story, which is the honest reason most teams migrate instead of syncing.

Trigger simple Zaps without middleware

Zapier covers a narrow slice of this without code, and the narrowness is worth stating plainly. The Umbraco app on Zapier is trigger only, firing on New Content Published and New Form Submitted with no actions of its own, so Umbraco can start a workflow but can never be its destination. Webflow supplies the write side, including Create Live Item and Update Item. The Umbraco half also depends on the Zapier integration package being installed in the solution, which rules it out when you do not control the deployment.

What you can build with Umbraco and Webflow

Almost everything worth building here is either a move or a read, and knowing which one you are doing saves a lot of argument later.

These are the patterns that hold up in practice:

• A one time content migration: read every Umbraco node through the Delivery API, map it to a collection schema, and write the items into Webflow so editors work in one place afterwards.
• A marketing site in front of a .NET application: keep product and account data in Umbraco where your existing services read it, and build the campaign pages in Webflow.
• A staged rollout: move one content type at a time and run both systems in parallel while the marketing team learns the collections and the redirects settle.
• An agent assisted content audit: ask an MCP client to compare Umbraco document types against your Webflow collection fields and list what still has no home.

Once the mapping is settled the rest is ordinary Data API work, so start with our guide to the Webflow CMS API and script the writes against a test site. Then install the MCP server in your AI client and let it scaffold the collections before you move a single node.