The wxrks WordPress connector pulls content from a site's WordPress REST API and creates a wxrks translation project from it. Today, every configuration in active use talks to a Zendesk Guide help center published through a WordPress-compatible endpoint — that's the connector's supported, working mode. This article documents that mode end to end.
💡 Who is this for? This guide is for Account Admins (or anyone your account has granted connector configuration access) who set up and maintain the WordPress connector. If you don't see Integrations in the sidebar, ask your account admin to grant connector access.
Key concepts
Term | What it means |
Configuration | A saved connection to one site's WordPress-compatible API, tied to a specific wxrks Organizational Unit. Multiple configurations can point at the same site — typically one per target language/Org Unit. |
Configuration Group | A set of configurations for the same site (same base URL, source language, and account) grouped together so one request can fan out across all their Org Units at once. |
Request | A queued ask to translate one post/article into one or more target languages. Requests wait in a queue until someone syncs them. |
Sync | Turning a waiting request into a real wxrks translation project — one project per Org Unit/target-language combination in the request's Configuration Group. |
Strategy | A required setting on every configuration that tells wxrks how to read and write back the site's content. Zendesk Guide is the strategy documented here. |
Before you start
Have the following ready:
The site's WordPress-compatible API base URL, plus a username and application password (or, for a site behind Cloudflare Access, a Cloudflare Access Client ID and Client Secret as well).
The wxrks Organizational Unit(s) that should own the translation projects — one per target language if you're translating into more than one. If you haven't created one yet, see How to create an Organization or Organizational Unit.
Connector configuration access in wxrks (see "Who this is for").
Step 1: Create a configuration for each target language
In the sidebar, select Integrations, then open the WordPress connector.
Switch to the Config tab and select Add Configuration.
Fill in the fields:
Field | What to enter |
Organizational Unit | The wxrks org unit that should own projects created from this configuration. |
Name | A reference name so you can recognize this configuration later. |
Workflows | Optional. If none are selected, syncs from this configuration use the org unit's default workflows. |
Base URL | The site's API base URL. |
Source Site | Optional. The public site URL, if it's different from the Base URL. |
Username / Password | Credentials wxrks sends as HTTP Basic auth on every API call. The password is encrypted before it's stored. |
Strategy | Required. Use Zendesk Guide (the working, supported mode — see "Good to know" below). |
Cookie User / Cookie Password | Optional, for sites that also require session-cookie authentication alongside Basic auth. |
Cloudflare Client ID / Cloudflare Client Secret | Only if the site sits behind Cloudflare Access — these are sent as the |
Parameters | Strategy-specific mapping parameters (for Zendesk Guide, this is where locale/site mappings are set up) — your implementation contact provides these. |
Select Create, and repeat for every target-language Org Unit you need on this site.
Step 2: Group your configurations
If you created more than one configuration for the same site (one per target language), group them so a single request can fan out to all of them. Switch to the Configuration Group tab and select Add Configuration.
Choose every configuration for this site and give the group a Name. All the configurations in a group must share the same base URL, source language, and account — wxrks rejects the group otherwise.
Step 3: Request a translation
Switch to the Requests tab and select Create new request.
Field | What to enter |
Configuration Group | The group created in Step 2. |
Post ID | The article/post's ID on the source site. Use Check Post ID to confirm it resolves before submitting. |
Post title / Post URL | Reference info shown in the request queue and later on the created project. |
Last publication of the post | The post's publish/update date. |
Workflows | Optional — defaults to the Org Unit's workflow (Translation only) if left blank. |
Target Languages | Every language you want this post translated into. wxrks routes each language to whichever Org Unit in the group is configured for it. |
Submitting adds the request to the queue with status Waiting. Requesting the same post again before it's synced merges the new languages/workflows into the existing waiting request instead of creating a duplicate.
Step 4: Sync the request into wxrks projects
From the Requests tab, select Create project for all Posts WAITING to sync every waiting request at once, or open a single request to sync just that one. Syncing splits the request into one wxrks project per Org Unit/target-language combination in its Configuration Group, and the request is removed from the queue once every language has a project.
If a target language was already synced for the same post from an earlier request, wxrks skips it and only creates projects for the new, non-conflicting languages.
Managing configurations and tracking status
The Entries tab lists every post that's been synced, with its current translation status per target language.
How delivery works
Once a synced post finishes translation in wxrks, the connector loads (or creates, if it doesn't exist yet) the localized version on the source site and publishes the translated content back into it automatically.
Good to know
Zendesk Guide is the supported strategy: every configuration in this wxrks environment currently connects to a Zendesk Guide help center exposed through a WordPress-compatible endpoint, not a self-hosted WordPress blog. The connector's config screen also lists a generic strategy for a plain WordPress site, but as of this writing that path isn't a finished, working option in wxrks — use Zendesk Guide, and check with your wxrks contact before configuring anything else.
Same-site grouping rules: every configuration in a Configuration Group must share the same base URL, source language, and account. Mixing sites or source languages in one group is rejected when you save it.
Merging duplicate requests: requesting the same post again while an earlier request for it is still waiting adds the new target languages/workflows/notes to the existing request instead of creating a second one.
Troubleshooting
Symptom | Likely cause and fix |
Saving a Configuration Group fails. | Check that every configuration in it shares the same base URL, source language, and account. |
Syncing a request reports a language left with no Org Unit. | One of the request's target languages has no configuration in the group set up for it. Add a configuration for that language's Org Unit, or remove the language from the request. |
A request won't sync and reports a conflicting project. | Another in-progress project already covers that post/Org Unit/language combination. Check the Entries tab before retrying. |
Quick reference
Task | Where |
Add or edit a configuration | Sidebar > Integrations > WordPress > Config tab |
Group configurations for one site | WordPress connector > Configuration Group tab |
Request a translation | WordPress connector > Requests tab > Create new request |
Sync waiting requests into projects | Requests tab > Create project for all Posts WAITING (or open one request) |
Check sync/translation status per post | WordPress connector > Entries tab |
API reference |
Related articles
Using the wxrks Connectors Interface — the connector UI chrome (entries, statuses, filters) shared across all connectors.