Run translation inside the systems you already have.

Context travels with the segment, not around it.

Notes attach to a segment, and can be overridden per target language; so the instruction the German translator needs is not the one the Polish translator gets. Comments work the same way: on a segment, in one language, or in all of them, addressable by your own segment ID. The character limit, the screenshot reference, the note that this string appears on a button reaches the person doing the work instead of sitting in the ticket that triggered 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 this usually gets wired to.

• A repository through CI, so strings are translated on merge and localized builds ship with the release.
• A headless CMS, so one editorial action publishes in every market instead of in one and a backlog.
• Documentation in Markdown, rebuilt in every language with each release rather than once a year.
• A product catalogue from a PIM, refreshed each cycle rather than re-exported whole.

Segments posted here run against the record your organisation has accumulated: approved terminology, memory of what people have already confirmed, and style rules that exist as configuration rather than a PDF somebody was meant to read.

Both terminology and style are applied while the translation is produced — not checked against it afterwards, and not re-sent with every request. Which is also why they hold when you change model.

Neither is a flat list. Terminology is grouped into domains you define — the vocabulary of your service manuals is not the vocabulary of your marketing site, and a term that is correct in one can be wrong in the other. Style guides sit one level lower again, selected per target language, because the register your German market signed off on is not automatically the one your Japanese market did.

So there are parameters, but they are pointers: a domainId on the project, a styleGuideId on each target language. What they point at (the approved terms, the rejected ones, the rules) stays on your account. You are naming which body of decisions governs this content, not shipping it with the request and hoping the model reads all of it.

Every decision is stored at the level where it was made — company, domain, language, segment. A request points at them. It does not carry them.

Omit the domain and nothing lapses. Your account-wide terminology is still enforced. The domain narrows which set governs a project; it is not the switch that turns governance on. An integration written in a hurry, by someone who has since left, does not quietly stop applying the terms your company approved.

For structured content that distinction is not aesthetic. One attribute rendered two ways across five hundred products is not a quality problem; it is a filter that stops matching.

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.

And a third answer, between the two: let the score decide.

Set serviceScoring on a target language and every machine-translated segment gets a quality estimate. The threshold beneath which a segment is routed to a human for revision is configured rather than passed — on the account, per domain, and per language pair — so the call says score this, and your settings say how good is good enough, at whatever level you actually made that decision. Above the line, the segment passes. Below it, a person sees it before anyone else does.

That is the option most pipelines do not have, and it is usually the one that pays. The choice stops being review everything or review nothing — a decision made per language, in advance, on a guess — and becomes review what measurably needs it, on a proportion you can watch. Raise the bar for the domain that carries liability and lower it for the internal knowledge base; raise it again for the language pair your machine translation is weakest in. Your risk tolerance stops being a policy nobody reads and becomes a number that decides who touches the segment.

Where you want people on it, the people can be yours.

team takes usernames with roles attached (project manager, translator, proofreader, in-country reviewer) and rates and currency where they apply. A project created by an API call arrives with its team already assigned, so nobody has to open the interface to hand out work that the calling system already knew about.

Where those people are freelancers, the costing is done for you. Rates against the volume actually assigned, in the project currency, calculated the same way whether the job was created by a person or by an HTTP request — so an automated pipeline does not turn into a spreadsheet somebody reconciles at month end.

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.