You are standing up a localization engine. The engine that translates well is not the empty one – it is the one that carries your brand voice, your glossary, and your instructions, so every translation sounds like your product and never mangles a term you have already decided about.
That knowledge usually exists before the engine does. It is sitting in a brand guidelines page, a style guide, a terminology sheet, a few paragraphs of rules a translator was once handed. Building the engine by hand means reading all of that and re-entering it as brand-voice, glossary, and instruction records, one at a time – tedious work that is easy to start and easy to leave half-finished.
The async provisioning API closes that gap: point it at what you already have. You POST links and raw text in one request, get an engine ID back right away, and an AI agent crawls the sources, extracts brand voices, glossary items, and instructions, and applies each to the new engine as it finds it. The engine is usable from the moment you get the ID – the configuration fills in as the job runs.
On this page
The problem#
A localization engine is only as good as its configuration. Model selection gets you a translation; brand voices, glossary items, and instructions are what make that translation match how your product already speaks – the formality you have chosen, the product names you never translate, the date format you always use. Those are the same primitives you would otherwise create by hand: brand voices, glossary items, and instructions on an engine.
The catch is that all of it already lives somewhere. A team that has shipped a product in one language has a brand guidelines page, a style guide, a glossary of terms support agents are told never to translate. To configure the engine by hand, you read those documents and transcribe them into records – decision by decision, locale by locale. It is slow, and the slowest part is the least interesting: copying knowledge that is already written down into a different form.
Provisioning removes that step. You hand the platform the documents themselves – as URLs to crawl or as raw text – and an AI agent does the reading and the transcription. It creates the brand-voice, glossary, and instruction records for you, on a real engine, applying each as it is identified. You review and adjust afterward in the dashboard, the same way you would edit anything you created yourself. The starting point is a configured engine, not a blank one.
Provisioning configures an engine; it does not translate.
This API builds and configures the engine. To translate with the engine once it exists, reach for the async Localization API for many locales at once, or the synchronous Localize endpoint for a single locale pair. Provisioning is the setup step that makes those calls carry your brand voice and glossary from the first translation.
How it works#
Three steps, and only the first one happens inside your request. The other two run on the platform, on their own time – which is why the call returns right away and the engine is usable before the work is done.
Submit your sources
POST a name for the new engine and an array of sources – URLs to crawl, raw text to analyze, or both – to /jobs/provisioning. The API creates the engine immediately and returns 202 with the engine ID (eng_) and the job ID (pjb_). Your application is free to continue; nothing about the response waits on extraction. See Create a provisioning job for the full request and response shape, and Source types for what makes a source worth submitting.
The AI agent crawls and extracts
Link sources are crawled in parallel and converted to text; raw content is read directly. An AI agent then analyzes everything and extracts three kinds of configuration – brand voices, glossary items, and instructions – applying each to the engine as it is identified. A source that fails to crawl, or a single item that cannot be created, does not stop the rest. What the AI extracts covers the three components and how they map to locales.
The engine is ready
When extraction finishes, the engine is fully configured and ready to translate through the Localization API. The platform reports completion – with a summary of everything that was created – to your webhook URL, or live over the job's WebSocket if you want to show progress while it runs.
The engine ID is usable immediately.
The eng_ ID in the 202 is a real engine the instant you receive it. You can store it, reference it, and translate against it right away – configuration is applied as the job runs, so a translation made early sees fewer extracted records than one made after the job completes. You never wait on provisioning to start using the engine.
Authentication
Every request – REST and WebSocket – authenticates with your X-API-Key header. Keys are organization-scoped and reach every engine in the org. See Authentication for the details, and API Keys to create one.
What you get back#
A skeptical reader is already asking the two questions that decide whether this is safe to depend on: what if a source is bad, and is this a black box I cannot correct?
Neither answer is hidden. Provisioning does not return a proprietary blob – it creates ordinary brand-voice, glossary, and instruction records on a real engine, the exact same objects you would create by hand, each editable afterward in the dashboard. When the job finishes it hands back a summary that names every record it created and every failure it hit, so you can confirm the configuration instead of assuming it. What the AI extracts walks through that summary and how a failed item is isolated to an errors list while the rest of the engine still configures.
Sources are also optional. Submit a name with no sources and you get a clean engine on defaults to configure yourself – Create a provisioning job covers that path alongside the 202 response shape. Provisioning is how you skip the manual setup, not a prerequisite for having an engine at all.
Generic pages produce generic config.
The configuration is only as good as what you submit – brand guidelines and terminology lists give the agent something concrete to extract; a marketing homepage yields almost nothing. Source types covers what to point it at.
That is the trade provisioning makes: you spend one request and a short wait, and in exchange you skip transcribing knowledge you already wrote down – point it at what you already have, and start from a configured engine. The pages below are the parts of that sentence.
