A headless stack already owns its rendering, so Universally slots in as a translation service your server calls rather than something that sits in front of your site. You send text, you get text back, and you decide where it is stored and when it is refreshed.
The API and the keys are covered in Integrate using the API. This page is about which parts of it fit a decoupled front end.
Which endpoint fits
The Translator API has two that matter here, and headless setups usually want the first:
/v1/translate/strings |
/v1/translate/html |
|
|---|---|---|
| You send | up to 500 strings per request | one rendered page |
| You get back | a map of source string to translation | the translated document |
| Fits | content coming out of a CMS as fields | server-rendered pages you were about to return |
With the strings endpoint your CMS stays the source of truth. Pull the fields you need, send the values, store what comes back against the same keys. Nothing has to guess which part of a page is content.
curl -X POST https://translator.universally.com/v1/translate/strings \
-H "X-API-Key: $UNIVERSALLY_KEY" \
-H "Content-Type: application/json" \
-d '{"strings":["Add to cart","Out of stock"],"targetLanguage":"es"}'
The response carries the translations plus a metadata block: stringsReceived, stringsTranslated, skippedStrings and limitReached. Read limitReached on every response. When it is true the reply is partial.
A string that was not translated is absent from translations, not returned unchanged. Look every key up with a fallback to your own source text (translations[s] ?? s), or you will render undefined. See Translate strings.
Repeat requests for text already translated are served from storage and cost nothing further. Sending fresh: true translates again and returns the result without storing it, so keep your own copy of anything you get that way: a later request without fresh still returns the stored translation. Those calls do not count against your word total either.
Keep the key server-side
The project key must not reach the browser. Anything in frontend JavaScript, in a mobile bundle, or in a repository is public, and the key can spend your word total. Call the API from your server or build step, then serve the stored result to clients. See Find your API key.
What you own
The WordPress plugin does several things beyond calling an endpoint. Through the API they are yours:
- A URL per language. Something must route
/es/pricing/to your Spanish render. Universally does not intercept traffic. See Subdomains and subdirectories for the shape to copy. - Storage and invalidation. Keep translations next to your content and re-send a string when the source changes. Translating on every request is slow and pointless.
- The language switcher. No widget is injected, so the markup and the state are yours.
- hreflang and sitemaps. The WordPress plugin emits hreflang alternates; your own front end emits its own
<head>, so those links are part of the integration. See hreflang tags.
What still works without WordPress
Anything that lives in the dashboard rather than the plugin applies to your content the same way:
- Glossary rules, applied when the translation happens, so brand names hold in the API path too.
- Edit translations manually for fixing a specific string.
- Language variants and regional targeting, since a variant is chosen by the language code you send.