Run translation inside the systems you already have.

Context stays with the segment

A note attaches to a segment. 'languageSpecificNotes' sets a different note for each target language, so the German translator reads one instruction and the Polish translator reads another. The character limit, the screenshot reference, the note that this string appears on a button reach the person doing the work rather than staying in the ticket that started the job.

Authorization: Basic <companyId:apiKey>

{
  "customId": "catalogue-2026.08",
  "name": "Product catalogue — August release",
  "taskId": "release-notes",
  "sourceLanguageCode": "en-US",
  "domainId": 7,
  "endDateUtc": "2026-08-28T17:00:00Z",
  "eventUrl": "https://your-system/hooks/textunited",
  "targetLanguages": [
    { "targetLanguageCode": "de-AT",
      "serviceTranslation": true, "serviceProofreading": true,
      "styleGuideId": 412 },
    { "targetLanguageCode": "pl-PL",
      "serviceAutomaticTranslation": true, "serviceScoring": true }
  ],
  "segments": [
    { "customId": "sku-4471.name",
      "content": "Telescopic mast, 12 m",
      "notes": "Product title — 40 character limit" },
    { "customId": "sku-4471.desc",
      "content": "<p>Rated to <b>12 m</b> working height.</p>" }
  ]
}

That single call is the integration. Everything after it is your own customId and a webhook.

What teams wire this to:

• A repository calls the API from CI, so strings are translated on merge and localized builds ship with the release.
• A headless CMS calls it on publish, so one editorial action reaches every market.
• A documentation build in Markdown runs in every language with each release.
• A PIM sends the product catalogue each cycle instead of re-exporting all of it.

Three things decide the output before the model sees it.

TextUnited applies all three while the translation is produced, not to the output afterwards, so they hold when you change model.

Each one is scoped, not global.

Terminology is grouped into domains you define, because the vocabulary of your service manuals is wrong on your marketing site. A narrower guide states only the rules that change at that level. The rules from the wider guides still apply.

The request carries pointers, not payload.

The terms and rules stay on your account. Omit the domain and nothing lapses: your account-wide terminology still applies, because the domain narrows which set governs a project rather than switching governance on.

You can also change your mind per release. The methodology lives on the target language of a project, not in your integration code — so moving a market from machine to human is a field in the next request, not a sprint.

Set a score threshold and it decides who reads the segment.

Set serviceScoring on a target language and every machine-translated segment gets a quality estimate. You configure the threshold rather than passing it: the call asks for a score, and your settings decide what counts as high enough. Above the threshold the segment passes. Below it, a reviser reads the segment before a customer does.

You then stop choosing between reviewing everything and reviewing nothing, and you set the threshold at whatever level you made the decision.

Your own translators can do the work.

team assigns users to a language project as project manager, translator, proofreader or in-country reviewer, and one person can hold several of those roles. A project created by an API call arrives with its team assigned, so nobody opens the interface to hand out work the calling system already knew about. Each member carries a translation rate and a proofreading rate in the project currency, so an API-created project costs what the same project costs when a person creates it.

Interactive schema is served from the service itself, so the contract you test against is the one that is deployed rather than a document that drifted from it. Every request accepts Basic or bearer credentials on the same path.