Platform guide

The TofuBofu Webflow integration, and why it asks before it publishes

By Arnav Mukherjee, founder of TofuBofu · September 3, 2026

On 31 August we published an article into a real customer's Webflow site and the write succeeded. The item appeared in their collection. Our card went green. Then we opened the page, and the post carried no headline at all.

Their collection holds sixteen fields and we'd filled four: Webflow's own name and slug, their rich text field, and their meta description. Among the ones we left empty were the field their template reads to render the H1, and a field named, with some irony, schema. The part that stopped me wasn't the empty ones though. Our article landed in the correct rich text field because that field happened to sit first in the collection. On a site whose first rich text field is an author bio, we'd have written a blog post into the author bio and reported success.

So our Webflow connector now asks you six questions before it will publish anything. Every other destination we ship gets to skip them. Webflow can't, and Webflow's own data model is the whole reason.

Only two fields on a Webflow collection are guaranteed to exist

WordPress hands every adapter on earth the same post schema: title, content, excerpt, status. You can write it blind into a site you've never seen and you'll be right. A Webflow CMS collection doesn't work like that. Webflow's own item editor splits a collection into Basic info, holding name and slug, and Custom fields, holding everything else. Those first two are the only fields every Webflow collection has. Every other field on every Webflow site was invented by whoever built that site, and named however they felt that morning.

An adapter that guesses field slugs is guessing at a schema its author has never seen. Lengthening the guess list doesn't make it safer, because the failure it produces is silent. The API returns success, the item exists, the card goes green, and the damage sits on a live company website until a human reads the page. Our adapter's file header carries the rule in five words: we ask, we do not guess.

Six roles, mapped once

Name and slug go in on every publish, because they're the two fields we can count on. Everything below travels only because you told us where it goes.

Underneath that screen sits a rule the build enforces on every destination we ship, Webflow included. For each field a destination has, an adapter does exactly one of four things and says which: derive the value from what we already hold, learn it from your existing posts, ask once at connect and reuse the answer forever, or decline it and state why. A field an adapter can see at its destination and never names fails the build, by name. "There was nothing to map" happens to be the sentence that let three of our adapters ship half filled, so the build stopped accepting it.

Connecting it, step by step

Two things have to be true before the screen does anything useful. Your brand needs a domain saved in Settings, because a publishing connection belongs to a website and not to a workspace, and we refuse with a named error when there isn't one. And your Webflow site needs a paid CMS or Business site plan, because the Data API won't write CMS items without one.

• Generate the token in Webflow: Site settings, Apps and integrations, API access, Generate API token. Select the scopes cms:read, cms:write and sites:publish.
• Paste it into the one credential field, Site API token. No OAuth flow, no marketplace app, no review queue.
• Press Fetch my sites and pick your Site from the dropdown.
• Pick your Blog collection.
• The field mapping panel appears in place. We read the live collection and list every field it has with its slug, its display name and its type, alongside what we'd pre-select and why we'd pick it.
• Change any row that looks wrong, then press Connect Webflow. The same button saves the map. On save we re-read the collection and drop any role naming a field that's gone or whose type can't hold what we write.

After that, the connected row carries a Review field mapping control, and you can reopen the map whenever your collection changes. The token itself never travels back to the browser.

One behaviour on that screen deserves calling out, because it's a deliberate choice and it looks like laziness. An optional role gets filled only on a name match, never on a guess. An empty optional field is one you can see and fix. A wrong one is your article's title sitting inside a pull quote on a live page. Only body falls back to field order, because a post with no body isn't a post, and when it does we stamp the row guessed and print the sentence in full: we guessed this from the field order, check it before connecting.

A published Webflow post is two API calls

Creating the item undrafted only stages it. Webflow's CMS holds the row, your readers see nothing, and every dashboard involved says success. The site itself has to be published, so we make a second call, and that call reads your site's custom domains first and publishes to those. Naming only the Webflow subdomain returns a clean 202 while your real domain stays stale, and a success message wrapped around a stale page is the worst kind of green tick.

Until 28 August our adapter stopped after the create and told the customer the article was live. Its own success note read "Open Webflow to review and publish" while the product said published. Both sentences shipped in the same response, and neither one flinched.

Now the result reports three outcomes instead of two: created and live, created but only staged, and not created. A staged item comes back marked draft even when you asked for published, and we keep the call marked successful on purpose, because the item genuinely exists. Telling you otherwise is exactly what makes somebody write it twice.

Webflow allows one successful publish queue per minute per site, so two articles back to back will hit it. We say that in those words instead of reporting an outage. Your item's already created at that point, so the move isn't our button: open Webflow and press Publish there. Our publish path looks for the existing item by slug and returns early, so a second press here finds it and won't retry the site publish for you.

The near miss that made us stop trusting a status code

On 20 August a customer pressed Publish. One item was created in their Webflow. Their browser got a 400. Nothing was broken except our own check: we tested for 200 or 201, and Webflow answers 202 Accepted, which happens to be the only documented success code for that endpoint. So the item existed, our card still read Draft ready, and the obvious next move for anyone looking at it was to press Publish again.

We call it the duplicate all over our codebase and no duplicate ever appeared. Pressing that button a second time would have put two copies of one article on a live company website, and the distance between "would have" and "did" was one person noticing before the customer did.

So we now look for an item with the same slug before any write, and again after any failure, because a write can succeed and still look like a failure. The lookup returns three answers, not two: found it, looked and it isn't there, and could not answer. An unreachable API and an absent item aren't the same fact. A connector that flattens them into one is a connector that writes twice.

Your FAQ schema stays with you unless you give it a field

Of the 39 B2B sites we crawled, 26 carried no FAQ schema whatsoever, 67% of them. The gap's real and it's worth closing. We still refuse to close it blind. Webflow's API can't read a post back to us, so we've no way to check what your live page ended up carrying, and on a connection with no schema field mapped the JSON-LD never leaves our side. You get it back through a Copy schema button on the content card and you paste it where you want it. A wall of raw JSON stranded in the middle of your live page is worse than no schema at all, so where we can't check, we don't embed and hope.

Map a schema field and the JSON travels with the write, bare and minified. Both of those are fixes for problems we measured rather than imagined. One customer's template supplies its own script tag, so ours had to come off. A rich text editor turned pasted indentation into non-breaking spaces, which JSON.parse rejects outright. The connect screen warns you when the field you picked is rich text, and tells you a plain text field is safer.

Four reasons this beats pasting it in yourself

One, a copy-paste leaves no record of what was sent. Every publish through the connector writes a single greppable line naming the provider, the deliverable, the workspace, the site, the requested status, the outcome, the external id and the error. We built it because on 20 August a real customer publish failed and the only place the reason was ever written down was a browser toast that clears itself after 2.2 seconds.

Two, one article can't become two. Covered above, and it's the difference between a connector and a fire-and-forget POST.

Three, one destination per value. When your schema has a field of its own, the body doesn't also carry a script block. When your hero has a field of its own, the body doesn't also carry a figure. The second half of that was missing until we measured it: a collection with a mapped hero received the image twice in one payload, once as the field and once at the top of the rich text, and on a template that renders its hero field, that's the same picture twice on your live post.

Four, the loop closes. A published deliverable gets marked cited when the next scan finds an engine naming your brand for that article's own target question. We count a transition only, and with no prior report we return nothing at all, because a brand's first scan already showing citations isn't a win we caused. Copy-paste breaks the chain at the first link. Nothing on our side knows the article exists, so nothing can referee it.

Worth aiming that at the right target. In our citation corpus, only 48 of 882 distinct cited sources had no path at all, 5.4% of them. Engines cite pages that answer a question, not companies. Read the number as a direction rather than a rate: it covers Google AI Mode and Bing Copilot across 55 scans, and four of those scans supply 95.8% of the sources.

Everything above the last point is plumbing. The plumbing exists so the re-scan means something.

Where the manual path still applies

The connector publishes articles into a collection. Your site-wide plumbing stays yours: robots.txt under Site Settings, Organization schema in the site-wide head code, real heading elements instead of styled text blocks. We've written that checklist separately and nothing here replaces it. And Webflow can't take a post back through its API, so a retraction is your click, not ours. We say so on the card and clear our own row either way.