Most requests I get for a new integration come from teams whose tools we don’t cover yet. Here’s how I’d decide, system by system, between the integrations we maintain, the ones our partners maintain and the ones you build yourself.
Version 4.8.6 of our WordPress integration, released on July 17, 2026, fixed a single bug. On multisite installations running MultilingualPress, translations could be published to any sub-site that shared the target language, instead of the source site’s own related sub-site. It’s the kind of bug that never fails a build. The page goes live; it just goes live in the wrong place.
That release was one of 16 between January and October 2026, and finding problems like it is a job in itself. We use AI agents to surface bugs proactively. For our connectors, an API drift-monitoring agent also reads the changelogs of the tools we integrate with, and opens a ticket whenever a change touches an endpoint we use. Some of those tickets are breaking changes we need to fix; others are new capabilities worth adopting. Had your team built its own WordPress connector, all of that plumbing would be yours to build and run.
That’s the argument for using an integration wherever one already exists. Where none does, our advice points the other way: build your own. We’d rather give you the tools to connect a niche system yourself than leave you without an option.
Three routes into the Phrase Platform
Phrase connects to more than 200 tools. Those connections come from three places, and each exists for a different reason.
- Native integrations. Phrase builds and maintains these itself, for the systems most customers rely on, such as Figma, GitHub and WordPress. They’re generally the most dependable option, because the team that owns the connector also owns the platform on the other end of it.
- Ecosystem integrations. Partners co-develop these with Phrase and maintain them, extending the platform into systems where the partner knows the territory best, such as Storyblok and Adobe Experience Manager. They can also earn Verified Solution status, Phrase’s mark of quality and compatibility.
- Your own integrations. For anything neither route covers, such as a proprietary CMS, an in-house documentation system or a niche platform, Phrase provides APIs for Phrase TMS, Phrase Strings, Phrase Language AI and Phrase Studio, along with webhooks, an MCP server and step-by-step guides on the Developer Hub.
The third route is a deliberate choice. We’re regularly asked to build one more connector, and not every request has a business case that justifies maintaining it indefinitely. Giving customers the tools to connect those systems themselves means nobody waits, and our engineers can focus on the integrations most customers need. Teams without the capacity to build can work with one of our implementation partners instead, so the integration gets built without landing on our roadmap or theirs.
One launch, three round trips through Phrase
Take a familiar product-team job. A feature ships in the app, and marketing launches it on the website, with help content to match, in eight languages on the same day. Each piece of content starts in a different tool and makes its own round trip: out to Phrase, where machine translation and human review run in whatever order the workflow sets, and back again.
- App UI (native). A designer sends the feature’s UI copy from a Figma frame to Phrase Strings with the Figma plugin, which creates keys and attaches screenshots for context. Translations come back into Figma, so the designer can check for overflow, truncation and right-to-left layout issues before developers ship the strings.
- Launch page (native). The web team builds the page in WordPress from the approved design, in the source language. The WordPress integration creates a translation project in Phrase TMS when the page is ready, then syncs translations back with page structure, custom fields and SEO metadata intact. It works alongside WPML or MultilingualPress, and Yoast SEO.
- Help center (your own). The in-app help content runs on a documentation system the company built itself. No connector exists for it, and none should, because nobody else uses it. So the team writes a small plugin against the Phrase TMS API: create a project from a template, upload articles as jobs, wait for a webhook when they’re done, and pull the translations back.
- Reuse. The launch page and the help articles both go through Phrase TMS, so its translation memory and term base apply to both, whichever integration brought the content in. The feature has the same name on the website and in the help center.
Swap WordPress for a CMS with a partner-built integration, like the ones above, and the second round trip looks the same. Only the maintainer changes.
Deliveroo runs the Figma plugin, Phrase Strings and Phrase TMS together, and its localization managers helped us test the plugin. With the Figma integration, the company cut its project timelines by three to four days.
What “maintained” looks like
The most persuasive thing we publish about our WordPress integration may be the changelog, because anyone can check it. Group the 2026 entries and a pattern appears:
- Platform and plugin changes. Testing against WordPress 7.0, Elementor work in five separate releases, and fixes for Advanced Custom Fields link and WYSIWYG fields that weren’t exporting as translatable text.
- Data handling. Image URLs rewritten as base64-encoded SVGs, plain custom fields overwritten by a neighboring WYSIWYG field, and newly added target languages ignored until a post was saved again.
None of these is exotic. Each is the ordinary result of connecting two systems that both keep changing. The worst ones fail without fanfare: a field that exports as plain text, or a translation that doesn’t appear until someone happens to re-save the page, looks fine to everyone except the reader.
Where an integration already exists, those fixes land in our sprint. What stays with your team is configuration: which content goes for translation, into which languages, through which workflow. Our earlier piece on why the best product localization stories are the ones nobody tells explores why that matters to product teams. The changelog shows what it looks like, release by release.
Extend before you rebuild
Between using an integration as it is and building your own sits a middle option: keep the maintained integration and extend it where your setup differs.
- Hooks in the integration itself. In October, the WordPress integration added two PHP filters that let a site declare which custom Gutenberg block and shortcode attributes are translatable, in its own version-controlled code rather than only through the admin screen. We keep maintaining the integration; the configuration specific to your site lives in your repository.
- The Phrase MCP Server. Lets an AI assistant check job status, run quality checks or start routine work in plain language. It acts as the signed-in user, with that user’s existing permissions, so it can never do more than they could in Phrase itself.
- Phrase Orchestrator. Chains extra steps around any connector. A workflow can start from an event, such as a job being created, or from your own systems by webhook, and call back out to them when it needs to.
Two Orchestrator examples show the range. We’re building a Contentful workflow that’s far more configurable than the connector’s out-of-the-box Automated Project Creation, for customers with very large Contentful directories. And some teams use Orchestrator to skip human review for specific languages or low-risk content: routing that only makes sense for them, and that they set up themselves.
Building your own: what to plan for
When no integration exists, building one is the right call, and we document the route in detail. Our guide to building a TMS plugin covers the whole lifecycle: authenticate, create a project from a template, upload content as jobs, monitor progress, export translations and mark jobs as delivered.
The guide is also candid about what separates a working prototype from a production plugin.
These are the parts to plan for:
| What a production plugin needs | What it involves |
|---|---|
| Authentication | Exchange an API token for short-lived access tokens, cache them, refresh before expiry and retry once on a 401 |
| Content conversion | Turn your content into a file format Phrase accepts, such as XLIFF or JSON, and map the translations back into your system’s structure, including rich text and tags |
| Progress tracking | Webhooks as the main signal, with polling as a fallback for missed events |
| Idempotency | A stable key for every create, export and delivery step, so a retry never duplicates work |
| Retries and rate limits | Exponential backoff with jitter on 429 and 5xx responses |
| Live preview (optional) | An HTML source or preview package, so translators see the layout |
| Observability | Correlation, project and job IDs, status codes and latency logged on every call |
| Testing | Happy, failure, resilience and update paths |
| Ownership after launch | Someone to watch for API changes and fix what breaks, for as long as the plugin runs |
Localization adds requirements of its own: right-to-left text, plural forms, rich-text tags, fonts that aren’t installed, language codes that don’t match between your system and Phrase, and often a different workflow for each content type or region. AI coding assistants can now write much of this, and quickly, which makes building your own more realistic than it was even a year ago. The last row is the one to plan for: it starts on launch day and runs for as long as the integration does.
Map your stack before you estimate
Before your team estimates its next localization integration, ask one question of each system in the stack: is there an integration we can use, one we can extend, or a gap to fill ourselves or with a partner? Expect a different answer for different systems.
Browse the integrations hub to see what Phrase and its partners already maintain, and visit the Developer Hub for the APIs, webhooks, MCP server and plugin guides when it’s time to build the rest.
