Finished articles, as items in your Webflow collection.
Webflow has no fixed blog schema — every collection defines its own fields — so this integration is built around that rather than around a guess. You name the collection and we check its field slugs before anything is written, which turns the commonest Webflow mistake from an opaque 400 at publish time into a sentence at setup time.
Five fields, mapped to whatever your collection calls them.
Item content goes into fieldData, keyed by the collection’s own slugs. The defaults below are the slugs Webflow’s own blog template ships with; if your collection uses different ones, the connection carries your mapping instead.
| What we send | Default slug, and what it does |
|---|---|
| Titlename | Required. Verification fails if the collection has no such field. |
| Slugslug | Required. The item URL, and how we build the public link. |
| Bodypost-body | Required. Rich text; receives the article HTML. |
| Summarypost-summary | Optional. Receives the meta description. |
| Imagemain-image | Optional. Receives { url, alt } for Webflow to re-host. |
Verification checks the mapping, not just the token.
Testing the connection reads the collection and compares its field slugs against the three we cannot do without — title, slug and body. If any is missing, verification fails and the message lists the slugs your collection actually has, so the fix is a copy and paste rather than an investigation.
That is the whole reason the check exists: a mapping that does not match the schema is the commonest Webflow misconfiguration, and Webflow’s own answer to it at publish time is a 400 that names nothing useful.
What a token can do is all Webflow will tell us.
A site API token with cms:write that can read the collection can create items in it, and Webflow exposes no finer-grained capability probe short of actually writing something. So verification reports the collection it connected to and stops there, rather than inventing a permissions claim.
That is a real difference from WordPress, where the user’s capabilities come back on the same call and we can say whether they may publish.
On Webflow these are two different endpoints, not a status field.
Everywhere else in this family, “draft” is a value in the payload. Here it is a different URL, and the difference matters enough that the connection’s setting selects the route rather than a flag.
Draft — a staged item.
POST /collections/{id}/items with isDraft: true. The item exists in your CMS for someone to read and approve; nothing is on the published site. Updates go to PATCH /collections/{id}/items/{item_id}.
Live — the /live routes.
POST /collections/{id}/items/live, and PATCH …/items/{item_id}/live for updates. The item is pushed to the published site immediately.
What we deliberately never call: a site publish.
Webflow can publish an entire site, and doing that would be the lazy way to make a staged item appear. It would also ship whatever else is sitting unpublished in the designer — a half-finished homepage, a pricing change nobody approved — on our schedule rather than yours.
So we use the live item routes, which affect the item and nothing else. Your unrelated design work stays unpublished until you publish it.
Webflow re-hosts them, so there is no upload step.
An image field takes { url, alt } and Webflow fetches the file and copies it onto its own CDN when the item is saved. That is why this adapter has no upload call at all — the platform does the re-hosting that the WordPress adapter has to do itself.
The corollary: it has to be a URL Webflow can GET.
With no image provider configured — every trial account, by default — our illustrations are generated SVGs carried inline in a data URL. A remote server cannot fetch one of those, and handing it to an image field makes Webflow reject the entire item.
So the image field is simply left off when there is nothing fetchable to put in it. Losing a thumbnail is a bad trade; losing the whole article over its thumbnail is not a trade at all.
The body keeps its pictures either way.
Only the mapped image field goes unset. In-body images are inside the HTML that lands in your rich-text field and render from the item itself, so the article is never text-only because of this.
Configure an image provider and the hero URL becomes an ordinary https one, Webflow fetches it, and the field is populated as normal.
Three things this integration does not do.
Stated here rather than discovered later. Each is a consequence of what the Data API offers for a collection item, not an oversight we are planning around.
| Not done | Why, and what happens instead |
|---|---|
| The public URL is best-effort | Webflow does not return an item’s page URL, because where a collection item renders is a site-design decision rather than a CMS one. We build the link from the site URL you gave us plus the item slug. If your collection pages sit under a path, the recorded link will be missing it. |
| No categories, tags or reference fields | A category on a Webflow collection is a reference to another collection’s item, which we would have to guess the shape of. So the connection’s category and author settings are not sent to Webflow at all — they exist for the platforms that have a native equivalent. |
| One collection per connection | Every article from a connection goes into the collection you named. There is no routing rule that sends some articles to one collection and some to another. |
When Webflow says no.
401 — the token was revoked, or it does not carry cms:write. 404 — the collection id is wrong, or the token belongs to a different site; both are worth checking together, because a token from the wrong site produces exactly this.
Anything else surfaces Webflow’s own error message rather than a status code on its own. 429s and 5xx are retried with backoff; a 4xx is misconfiguration and is never retried.
Updates go to the item we created.
The item id Webflow returns is stored against the article, and publishing that article again patches that item — on the staged or the live route, matching the connection’s current setting. If you delete the item in Webflow, the next publish creates a fresh one rather than failing forever on an id that no longer exists.
Four rules that do not depend on which platform you use.
The mapping and the two routes are Webflow’s. These four are the pipeline’s, and they hold identically for a WordPress or Shopify connection.
Nothing publishes until the credentials verify.
A connection is saved unverified and is not used. Verification is a real call to your platform — it reports who we authenticated as and, where the platform will say, whether that identity may publish at all. Change the URL or any credential and the connection goes back to unverified until it is tested again.
Draft or live is your choice, per connection.
Draft is the default: articles arrive unpublished and nothing is public until someone presses publish on your side. Choosing live is a deliberate switch, and the screen says in plain words that nobody on your team will see the article first.
A publish that fails is reported as failed.
The failure is stored against the article with the reason the platform gave, and the job is marked failed rather than done. A 4xx is treated as misconfiguration and is not retried — retrying bad credentials against your site is how one wrong password becomes an IP ban.
An article that fails a hard SEO rule never reaches this stage.
The publish step is only queued for a draft that passed review and that a model actually wrote. An article held back says which rule held it. That gate sits before every adapter, so it applies to all four equally.
Straight answers.
Do I need to build a blog collection first?
Yes. Rankli writes into a collection; it does not create one, and it does not touch your site design. If you started from Webflow’s blog template the default mapping already fits. If you built your own, you will need to tell the connection which slugs mean title, slug and body — verification will not let you past until those three resolve.
Where does the article body actually go?
Into the field you mapped as the body, as HTML — headings, paragraphs, lists, links and images. It is a rich-text field’s content, not a set of Webflow components, so it renders through whatever styling your collection page applies to that field.
Can it publish to a Webflow site that is not published yet?
Items can be created either way, but the live route puts an item onto a published site — if the site has never been published, there is nothing for it to appear on. Draft is the sensible setting until your site is live, and it is the default.
What scope does the token need, and can I limit it further?
cms:write, on the site holding your collection. That is the narrowest scope that can create items, and it is not an all-sites or all-scopes token. We store it write-only, never display it back, and scrub it out of any error message before that message is stored or shown.
Point it at a collection and read the first three items.
$1 once buys 3 finished articles, created as staged items in your collection unless you choose otherwise. Nothing renews.