You have content in one language and users who read in many. The API exists to close that gap programmatically: you send text, you get it back translated, and every translation runs through a localization engine you configure once. The engine applies your glossary, brand voice, instructions, and per-locale model selection on every call – so the output reads the way your team decided it should, not the way a generic model guessed.
That leaves one decision: how much you need to translate at once. Translate a single locale in one request and read the result straight out of the response, or hand the platform many locales and let it translate each one as an independent background job while your app stays responsive. This page covers the base URL, that one decision, and where to go next.
What this API assumes
This is the reference for translating programmatically. It assumes you have decided to localize from your own code or pipeline – not through the dashboard – and that you have an API key. New to the platform? The localization engine concept is the one to understand first; everything here runs through it.
On this page
- Base URL
- Two ways to translate
- Asynchronous: many locales as jobs
- Synchronous: one request, one response
- Next steps
Base URL#
Every REST endpoint in this reference lives under one host:
https://api.lingo.devEvery request also carries one header, X-API-Key. The key is organization-scoped and shown once at creation; the full rules for sending it live on Authentication, and what comes back when a request is rejected lives on Errors and status codes.
Two ways to translate#
The same engine, the same glossary and brand voice, sits behind both modes. What differs is who owns the wait.
A synchronous call translates one locale pair and returns the translated data in the response. It is the simpler call – one request, one response, no endpoint to run on your side – and it is the right reach when you need a single locale and can wait for one round-trip.
But content rarely ships to one locale. A training module reaches 14 languages; a CMS entry fans out to every market you sell in. Fire one sync call per locale and you own 14 round-trips and the retry logic when one fails; wait on a single sync call for all of them and you block on the slowest. Therefore the API also offers an asynchronous mode: you POST your content once with the target locales, get a 202 immediately, and the platform translates each locale as an independent background job – owning the retries and the failure isolation while your app stays responsive.
Reach for async when the job is too big, too slow, or too many-locale to block on. Reach for sync when one locale pair in one response is all you need. The async pages come first below because they carry the most, but neither is the "real" API – they are two shapes of the same engine.
Asynchronous: many locales as jobs#
One request, every locale, results as they land. The async API takes one submission, creates one job per target locale, and delivers each result the moment it finishes – by webhook or WebSocket – without your app blocking on any of it.
Synchronous: one request, one response#
When you need one locale pair and can wait for the round-trip, call a sync endpoint and read the result straight out of the response – no webhook endpoint, no polling.
Next steps#
Whichever mode you pick, the engine behind it is yours to tune. Mint a key, then shape what the engine does on every call – the model it selects per locale, the terms it must translate exactly.
