This article covers the errors and failure modes people actually run into with the wxrks–Webflow connector — delivery errors, missing content, and connection or sync problems — organized by symptom, with the fix for each.
💡 Who is this for? This guide is for Account Admins and Project Managers who need to diagnose and fix delivery, sync, and connection errors in the wxrks–Webflow connector.
For how the connector works day to day — setup, content scanning, Components, and Field exclusions — see wxrks - Webflow Connector.
Error: "This item has no '…' locale variant in Webflow yet"
Symptom: a CMS item fails to deliver, and the Runs page shows an error like "This item has no 'fr' locale variant in Webflow yet." This is the single most common delivery error on sites that enabled Localization after they already had content.
Cause: in Webflow, an article and its French version are not two separate items — they are one item with two language versions, tied together by the same underlying ID. That shared ID is what makes the language switcher work: a reader on the English article who clicks "FR" lands on that article, rather than on a different one.
Creating that second language version is something only Webflow's own interface can do. Their API — which is what every connector, including this one, uses — cannot. From Webflow's own documentation: "For any Collection items that already exist, you must add the desired secondary locales in the CMS panel within the Designer. You can't add a new locale to an existing item via the API."
So when an item has never had a version in that language, the translation is finished and waiting in wxrks — there is simply nowhere in Webflow to put it yet.
Fix — create the language version in Webflow:
Open the CMS panel in Webflow and switch the locale selector to the target language.
Open the item. Webflow offers a Translate all fields button that machine-translates every field at once — or you can hover over a single field and click the globe icon to translate just that one.
The quality of that machine translation doesn't matter here. The point is that clicking it creates the language version of the item. Your real translation from wxrks overwrites it on the next delivery.
Then nothing needs re-translating. The connector retries failed deliveries about once an hour, or you can click Redeliver on the errored row in Runs to push it immediately. From that point on, that item syncs automatically forever.
To see which items still need it: switch the CMS panel to the target language and look at the item list. Each language has its own set of items, so anything missing from that list still needs its language version created.
This is a one-time backlog affecting content that existed before localization was enabled — worth clearing in one pass before a large send, rather than discovering it error by error. See Before you translate: every item needs its language versions in the setup guide.
A delivered translation shows an error
When wxrks finishes translating a document, the connector downloads the translation and writes it into your Webflow site. If that final write fails for a specific document and language, the Runs page shows an Error status on that row — together with the exact reason Webflow reported, including which field was rejected.
An error here never means the translation was lost. It is safely stored in wxrks, and the connector automatically retries failed deliveries about once an hour. You can also fix the cause and click Redeliver on the errored row to push it again immediately.
The most common causes:
The item has no locale variant yet (CMS items). By far the most frequent cause — Webflow's API cannot create a new language version for an item that already existed before that language was enabled. See the section above for what it means and how to fix it.
The translated slug is already taken. With Slug handling set to "Translate" or "Transliterate", two items whose translated names collapse to the same words can produce the same slug — and Webflow requires slugs to be unique per language. The connector resolves this automatically: it delivers all the translated content, keeps the item's existing slug, and shows a note on the run explaining what happened. If you want a distinct translated slug anyway, adjust it manually in Webflow afterwards. Choosing "Keep the source slug" in Settings → Slug handling avoids slug collisions entirely.
A field's character limit was exceeded. Translations often run longer than the source text. If a plain-text field has a maximum length configured in Webflow, an overlong translation is rejected and the error names the field ("Field value exceeds maximum length…"). Shorten that segment in the wxrks editor and redeliver — or raise the field's limit in Webflow's collection settings.
Broken formatting in a rich-text field. If HTML markup was damaged during translation (for example a deleted closing tag), Webflow rejects the value. Repair the segment's tags in the wxrks editor and redeliver.
A technical value came back altered. Fields that hold non-language values (option lists, CSS class names, internal codes) can fail validation if translation changes them. Prevent this class of error entirely by excluding those fields in Settings → Field exclusions (or, for component text, Settings → Component property exclusions) — they will stop being sent to wxrks at all.
The fix workflow is always the same:
Open Runs, expand the run, and read the error on the failing row — it names the field and the reason.
Fix the cause — in the wxrks editor, in Webflow, or in the connector's Settings.
Click Redeliver on the row, or simply wait: the connector retries on its own every hour.
One reassurance worth repeating: a delivery error affects only that one document and language. Every other document in the run delivers normally, and nothing already translated is lost.
The connector says it's disconnected from wxrks, or "Save & test connection" fails
Symptom: in the connector's Settings → wxrks connection → Keys, clicking Save & test connection fails, or a connection that used to work starts rejecting every send.
The connector authenticates to wxrks with one access key and secret pair, generated on a specific wxrks user's own My Account → Security page (the API Token section). That ties the connection to one person's account, which explains most of the ways it can break:
The key or secret was mistyped. Both are validated the moment you click Save & test connection, so a typo shows up immediately as an authentication failure rather than on your first real send.
The key pair was regenerated. Clicking Generate again on the API Token section creates a brand-new key/secret pair and immediately invalidates the old one — there is only ever one active pair per user. If someone on your team regenerated it (for this connector or for anything else using that same key), the connector's stored credentials stop working until the new pair is copied into Settings → wxrks connection → Keys and saved again.
The wxrks user's account was deactivated. If the person whose key the connector uses left the team or was deactivated, their credentials stop authenticating entirely. Reconnect using a key generated by a currently active user — ideally a shared or role account rather than one tied to a specific individual, so this doesn't recur.
A sub-user's key was used. wxrks sub-user accounts cannot authenticate through the API at all. If the key came from a sub-user, generate one from a full user account instead.
The API IP Whitelist is blocking the connector's requests. This applies specifically when the connected wxrks user is an Account Admin: if that account has any IPs configured under API IP Whitelist (same page as the API Token section, shown above), only requests from those IPs are accepted — everything else is rejected, even with a correct key and secret. Add the Webflow app's outbound IP range to the whitelist, or connect using a non-admin user's key if IP restriction isn't needed for this integration.
After fixing the cause, re-enter the key and secret in Settings → wxrks connection → Keys and click Save & test connection again — a successful test confirms the fix immediately, before you need to send anything.
Recurring automations run, but nothing ever comes back to Webflow
Symptom: a recurring pull content automation is active and the Pending Queue shows new/changed content being picked up, but translations never deliver back into Webflow on their own — and the connector's Webhooks tab (Settings → wxrks connection → Webhooks) never shows Active.
Cause: that tab only turns Active once wxrks actually delivers a webhook event to the URL you registered. Two things have to line up in wxrks for that to happen, beyond the webhook URL itself being pasted into the right event configuration:
Webhook events must be enabled on the Organizational Unit the projects are created under. In wxrks, go to the org unit's Notifications tab and confirm Enable Webhook Events is on — if it's off, no webhook fires for that org unit's work units at all, even though the webhook URL and event subscriptions in wxrks are configured correctly.
The projects the connector creates must land in that same org unit. The org unit is chosen under Advanced in the connector's Send to wxrks wizard (Step 1 — Settings). If sends are landing in a different org unit than the one you enabled webhooks on, check that setting.
Once both are true, the next status change or finished translation triggers a real delivery and the Webhooks tab flips to Active. This doesn't affect one-time sends triggered manually from the Translate page in the same way — those still complete and can be redelivered by hand from Runs — but any workflow that depends on the connector reacting automatically (recurring automations, review-workflow status updates) needs a working webhook to do that.
A static page or component shows no word count (or "0 words")
Symptom: in the content browser, pages and components show 0 words (or a dash) instead of a real number.
Cause: word counts are precomputed for CMS entries only. For static pages and components, computing a word count up front would require fully scanning every page of the site just to browse the list, so the connector deliberately skips it — the number you see next to a pages folder is a page count, not a word count.
Fix / clarification: a page or component showing no word count is not empty. The real, counted word total appears after you send it, on the Runs page (per work unit and per run).
A brand-new page doesn't show up in the connector
Symptom: you just created a page in Webflow and it isn't listed in the connector's content browser yet.
Cause: the connector caches the site's page list for up to ~30 minutes to keep browsing fast.
Fix: wait — a page created moments ago can take up to that long to appear — or reopen the Translate page to force a refresh sooner.
I sent a page but some of its text didn't arrive
Symptom: after sending a page, part of its visible text is missing from the wxrks project.
Cause: this is almost always about how that text was built in Webflow, not about the page selection. Text can live in several different "homes" — plain page elements, Components, CMS fields, HTML embeds, or images/SVGs — and only some of those belong to the page itself. See wxrks - Webflow Connector's "What does the connector scan?" section for the full breakdown of what's scanned and what isn't.
Fix / diagnostic tip: open the page in the Webflow Designer and click the "missing" element. The Designer shows you immediately whether it's a component instance (green outline / component panel) or a CMS-bound element — that tells you which section of the connector actually covers it, or whether it's out of scope (embed, image text) and needs a manual step.
My pages don't appear in Settings → Field exclusions
Symptom: static pages are missing from the Settings → Field exclusions screen.
Cause: Field exclusions applies only to CMS collection fields — it lets you mark specific fields of a collection (e.g. a SKU or a color code) as not-for-translation. Static pages don't have fields, so they are never listed there. That's by design, not a missing page.
Fix / where to go instead: use Settings → Component property exclusions — the equivalent control for page and component content, where you can exclude specific component properties (e.g. a width setting or a CSS class stored as text) from translation. See the Field exclusions section of wxrks - Webflow Connector for more on both controls.
Webflow doesn't match the translation I made on wxrks
Symptom: a translation that finished and was reviewed on wxrks doesn't match what's currently live in Webflow.
Cause: the same document was sent again in a later run — by a teammate, a test, or an automation — and Webflow keeps only one version of a locale's content, so the newest delivery always wins. Nothing is lost on the wxrks side: the original reviewed translation still exists in its original run, it's just not the version currently live in Webflow.
Fix: open the document's History on the Translate page to find the run with the correct translation, open that run on the Runs page, and click Redeliver on that document's row and language. See wxrks - Webflow Connector's "Multiple deliveries, overwrites, and history" section for the full mechanics of runs, deliveries, and history.
When I send to translate, the target shows a different language than I expected
Symptom: in the Send to wxrks wizard on the Translate page, the target language isn't the one you expected — it shows a different variant (fr-fr where you expected fr, or the other way around), or it doesn't match what your other sites send. The wxrks project then shows that same unexpected code, and Translation Memory matches from your other sites' projects don't appear.
Cause: the connector doesn't choose target languages itself — it pulls them directly from the locales configured in Webflow → Site settings → Localization, and sends wxrks exactly that locale tag. Webflow lets each site register a language either as a bare language (French — fr) or as a regional variant (French (France) — fr-FR), so two sites that picked differently produce two different wxrks language codes for what is really the same language. wxrks treats those codes as distinct languages: Translation Memory and its matches are keyed by the language code, so projects sent as fr-fr won't see TM built under fr — even inside the same Organizational Unit.
Fix — change the locale in Webflow, and keep variants consistent:
To change the target the connector sends, change the source it reads from: open Webflow → Site settings → Localization on that site and edit the locale to the variant you want — the same one your other sites use, ideally matching the language codes configured on your wxrks Organizational Unit.
Nothing changes in the connector: the very next send automatically picks up the corrected tag. Projects created before the change keep the code they were originally sent with.
Rule of thumb: pick one variant per language across every site that shares a wxrks Organizational Unit — bare (fr) or regional (fr-FR) — and use it everywhere. It's worth a quick check of the Localization settings every time a new locale is enabled on a new site, before its first send.
Still stuck?
Search the wxrks Community for similar questions, or contact [email protected] with the run ID from the Runs page — that lets support see the exact error Webflow returned without you needing to reproduce it.
Related articles
wxrks - Webflow Connector — setup, content scanning, Slug handling, and Field exclusions.