Keys & environments
A Langsys project issues two kinds of API key. Which one you use depends on whether you're discovering new phrases (development) or just displaying finished translations (production). Both are minted in the dashboard — the Quickstart walks through it.
Two keys, two jobs
| Key type | Can do | Use it in |
|---|---|---|
| Write | Fetch translations and register newly-discovered phrases into the project. | Development / server-side. Keep it out of public bundles. |
| Read-only | Fetch translations only. Cannot register or modify anything. | Production / the browser. Safe to ship in client code. |
Why a read-only key is safe in the browser. It physically can't write — the worst anyone can do with it is read the same public translations your users already see. That's the whole point of the split.
The typical flow
- Develop with a write key. As you build the UI, new phrases are discovered, registered, and machine-translated into your target locales.
- Once the copy settles, switch the deployed app to a read-only key.
- Users fetch the finished catalog; nothing they hold can change your project.
# .env.local — development
VITE_LANGSYS_PROJECT_ID=your-project-id
VITE_LANGSYS_API_KEY=write-key # discovers + registers new phrases# production
VITE_LANGSYS_PROJECT_ID=your-project-id
VITE_LANGSYS_API_KEY=read-only-key # only fetches — safe to shipWhat a project holds
The key authenticates against a project, which defines the translation universe for your app:
- a base locale — the language your source phrases are written in;
- a set of target locales — everything phrases get machine-translated into;
- machine-translation settings — the provider tier and whether new phrases auto-translate.
Running these demos locally? Point the SDK at your own instance with a read-only key — see the project's .env.example. Otherwise the panels run in demo mode (source text only).