Webflow
Create a site API token, pick the CMS collection your blog posts live in, and articles publish as live items in that collection.
What connecting it does
Hoxigen writes into the collection you already designed. At setup it reads the collection's fields and maps them itself: the rich text field becomes the article body, a plain text field named something like summary or excerpt takes the meta description, an image field takes the featured image, and a date field named for publishing takes the publish date. You are not asked to add fields or rename anything.
Items are created live, not as staged drafts, so an article appears on the published site rather than waiting for the next Webflow publish.
The public URL is built from the site's own host — your custom domain when the site has one, the webflow.io subdomain when it does not — plus the collection page path you confirm at setup.
What it needs from you
The same steps the connect screen walks you through, so you can see the whole of it before you sign up for anything.
- 1Open API access
In Webflow open the site's Settings, then Apps and integrations, then API access.
- 2Generate a token
Click Generate API token, name it Hoxigen, then set these three (click any to copy): to Read and write, to Read-only, to Read and write.
- 3Copy the token
Webflow shows it once. Copy it and paste it into Hoxigen.
- 4Choose the blog collection
After the token verifies, pick the CMS collection your blog posts live in and confirm its page path — /blog, for instance. Article links are built from that path.
What actually gets published
Field by field, so nothing arrives as a surprise.
Created straight to live in the chosen collection, with the article title as the item name and the article slug as the item slug.
Whichever rich text field the collection has. It is the one field the collection must have — without it there is nothing to publish into.
Mapped automatically if the collection has them, quietly skipped if it does not. An article with no image of its own leaves the image already on the item alone.
What happens when an article is refreshed
Yes — the same live item, patched in place.
Hoxigen locates the item by the slug in its URL, re-reads the live item's name and body, and compares them with what the refresh was drafted from. A mismatch means the item was edited in the Webflow Designer or Editor, and the refresh is refused as a conflict.
Otherwise the item is patched live, slug untouched, so the article's URL and whatever it has earned stay put.
You can also move to a different collection later without re-pasting the token — the collections your site offered are kept from setup.
Refreshing an article rather than writing a new one is how a page that used to rank keeps ranking.
What it cannot do
You would find these out in week two anyway. Here they are in week zero.
No rich text field, no article body, and the connection is refused at setup with that reason.
Webflow's rich text API rejects code blocks, so a code block is published as a paragraph. If your blog is a developer blog, this is the connector's real cost and we would point you at the webhook instead.
Articles go to the collection chosen at setup. You can switch it; you cannot publish to two.
Hoxigen backs off and retries once when Webflow rate-limits a write, and reports the failure rather than hiding it if the second attempt is refused too.
Everything on this page describes what the connector does today. Found something that does not match what you see in the product? hello@hoxigen.app — we will correct the page.
How publishing works, whichever you pick
Drafts land in your queue with their images, meta description and internal links, plus a short FAQ where readers need one. You can edit, approve or reject each one. Ignore the queue and it publishes on schedule anyway — that is the point of an autopilot. Prefer to sign off first? Set the connector to Approve first.
Connect two blogs and each gets its own article per publishing slot, written for it. Hoxigen does not syndicate one body to several sites and hope search engines pick a winner.
Each connector verifies access against the real API before you save its publishing destination. OAuth sign-in stores the login first; choosing a collection and saving finishes the connection.
A publish that fails keeps the reason on the article and tries again, up to three times. If it still fails, it stops and tells you, so you can reconnect the site and retry it.
Publishing somewhere else
- WordPress
Our own plugin turns your site into a signed receiver. Articles arrive as posts and refresh at the same permalink.
- Shopify
Publishes to your store's blog through the Admin API, on your own domain, with the product-adjacent content Shopify stores rarely get around to writing.
- Wix
Publishes to your Wix blog with an API key you generate, converting each article into Wix's own rich content format.
- Ghost
Publishes articles to your Ghost publication with a custom integration, including cover and inline images, and refreshes the same post.
- Framer
Publishes articles into your Framer CMS collection, uploads cover and inline images, and refreshes the same article.
- Notion
Sign in with Notion and publish formatted articles with covers to your public blog collection.
- Any site, by signed webhook
One signed HTTP POST per article to an endpoint you own. Next.js, Rails, Astro, Django, a static build — if it can receive JSON, it can receive articles.
Give it your URL. See what it drafts.
Connect Webflow when you like what you read — nothing publishes before that.