At my previous job, our translation system was a Google Sheet.
One massive spreadsheet. Column A was the translation key. Column B was English. Column C was German. Column D was French. And so on. Fourteen languages across thirty-something columns. Hundreds of rows. Color-coded cells to indicate status — green meant done, yellow meant "someone is working on it," red meant missing. No formal system for that either, just a convention that half the team forgot about.
The workflow looked like this: a PM would add a new row, type the English string, then ping a translator on Slack. The translator would open the sheet, find the row (good luck if someone had reordered or inserted rows since), type the translation, and change the cell color. Then an engineer would manually copy the translations from the sheet into JSON files in the repo. Every. Single. Time.
You already know what happened. Translations got out of sync constantly. Someone overwrote a cell by accident — no history, gone forever. Two people edited the same row and one person's work vanished. The engineer doing the JSON export missed a row and we shipped a screen with half-German, half-English copy. The PM asked "is this translation approved?" and nobody could answer because there was no approval flow — just cell colors that meant different things to different people.
We eventually tried a proper TMS. It had a nice dashboard with status badges and team features. Big improvement over the spreadsheet. But it introduced a new problem: the only way to interact with it was through that dashboard. The engineers still had to manually export JSON. The CI/CD pipeline had no idea the TMS existed. We replaced a chaotic spreadsheet with an organized silo.
That experience is why I built Stringbase API-first. Not the dashboard first. Not the landing page. The API.
Here's what that means and why it matters.
The dashboard-only TMS is just a prettier spreadsheet
This is the thing that frustrated me about most translation tools. You move from Google Sheets to a dedicated TMS and yes — you get proper status tracking, history, roles, approval flows. All real improvements. But the fundamental interaction model doesn't change: someone still has to open a browser, navigate to a thing, and click buttons.
Every TMS markets their dashboard. Beautiful screenshots of translation grids, status badges, team collaboration. And sure, Stringbase has all of that too — it's important for reviewers, translators, and PMs who need to see what's going on.
But here's the thing. The people who create translation keys — engineers — don't live in dashboards. They live in terminals, IDEs, and CI/CD pipelines. If the only way to add a key is to open a browser, log into a dashboard, and click through a form, you've already lost.
An engineer finishes a feature, writes a new UI string, and now has to context-switch to a completely different tool to register that string for translation. That's friction. And friction means it doesn't happen — or it happens three sprints later when someone notices the German version still shows English.
Sound familiar? It's the same problem we had with the Google Sheet, just wearing better clothes.
What API-first actually means
API-first doesn't mean "we have an API." Every TMS has an API page somewhere in their docs. API-first means the API was the first thing built, the dashboard is a client of that same API, and every single feature is accessible programmatically.
In Stringbase, every action you can do in the UI, you can do via the API:
- Create and manage translation keys
- Push and pull translations
- Approve, reject, publish — individually or in bulk
- Manage glossary terms
- Import and export JSON
- Read comments and translation history
- Access production translations via OTA endpoint
The dashboard and the API are equals. There is no "premium API" or "API add-on." It's on every plan, including free.
What this unlocks for your workflow
When your TMS has a real API, your translation workflow stops being a manual process and becomes part of your engineering pipeline.
Push keys from CI/CD. Your build system can scan for new translation keys and push them to Stringbase automatically. No manual entry. No "I forgot to add it to the TMS." The key exists in your code — it exists in Stringbase.
Pull translations into your build. Instead of committing JSON files to your repo and praying they're up to date, pull the latest approved translations from Stringbase at build time. Always fresh. Always in sync.
Automate approvals. Got a translation that only changed a variable name or a number format? Write a script that auto-approves trivial changes and only flags meaningful ones for human review. The API gives you full control over the approve/publish pipeline.
Build internal tools. Your team uses a custom admin panel? A Slack bot? A CLI tool? Stringbase doesn't care what client you build — the API serves them all equally.
The key format problem (or: we escaped the spreadsheet and fell into JSON hell)
Here's a practical example that shows why this matters. Most teams that outgrow Google Sheets end up storing translations as flat JSON files:
{
"checkout.success": "Payment successful",
"checkout.error": "Payment failed. Please try again.",
"nav.home": "Home"
}
Simple. Works. Until you have 15 languages and 500 keys and someone commits a conflict in the French JSON file because two translators were working on it at the same time. Different failure mode than the Google Sheet, same root cause — multiple people editing the same source of truth with no proper conflict resolution.
With an API-first TMS, the JSON files aren't the source of truth anymore — the TMS is. You push keys via API, translations happen in Stringbase (AI-generated, then human-reviewed), and you pull the final JSON when you need it. One source of truth. No merge conflicts on translation files. No engineer manually copy-pasting from a spreadsheet at 11pm before a release.
Stringbase supports JSON import and export with conflict resolution built in. You can overwrite existing translations or skip conflicts. But the point is: you shouldn't need to manage JSON files manually anymore.
How Stringbase's API actually works
Practical stuff. Every request is authenticated with an API key (prefixed sb_live_ so you can grep your codebase for leaked keys). Standard REST. JSON in, JSON out.
Creating a key:
curl -X POST https://stringbase.io/api/v1/projects/PROJECT_ID/keys \
-H "X-API-Key: sb_live_..." \
-H "Content-Type: application/json" \
-d '{"name": "checkout.success", "value": "Payment successful"}'
That's it. Stringbase receives the key, AI-translates it to every target language configured in the project, and it shows up in the dashboard for review. One API call replaced what used to be: open dashboard → navigate to project → click "Add key" → type key name → type source text → save → wait.
Fetching production translations for a specific language:
curl https://stringbase.io/api/v1/projects/PROJECT_ID/translations/ota?lang=de \
-H "X-API-Key: sb_live_..."
This returns only published translations — the ones your team reviewed and approved. This is the OTA endpoint. Your app calls it at runtime and gets fresh translations without a redeploy. But that's a topic for another post.
Why most TMS APIs feel like afterthoughts
I looked at every major TMS before building Stringbase. Crowdin, Lokalise, Phrase, Tolgee, SimpleLocalize. They all have APIs. But there's a pattern:
Some features only exist in the dashboard. Want to manage glossary terms? Dashboard only. Want to configure notification preferences? Dashboard only. Want to see translation history? Dashboard only. The API covers the basics — keys, translations — but the deeper features are locked behind the UI.
That signals a design choice: the dashboard is the product, the API is a convenience. I wanted Stringbase to be the opposite. The API is the product. The dashboard is a convenience.
This isn't a knock on those tools — they're mature products with real customers and they made sensible decisions for their audience. But if you're a product team with engineers who ship fast and automate everything, an API-first TMS fits your workflow better.
The real test: can you build a complete integration without opening the dashboard?
That's the bar I set for Stringbase. Can a developer integrate translations into their app, push new keys, pull translations, and publish to production — all without ever logging into the dashboard?
The answer is yes. You can:
- Create a project and configure languages via API
- Push all your keys programmatically
- AI auto-translates everything
- Approve and publish via API (or set up automation)
- Fetch production translations via OTA endpoint
- Ship
The dashboard is there for your PM who wants to review German translations before they go live. For the translator who wants to refine the AI output. For the team lead who wants to check what changed this week. But none of them are bottlenecks anymore — the engineering pipeline doesn't wait for dashboard clicks.
Where this is heading
SDK packages for React, React Native, and other frameworks are coming. A CLI tool for CI/CD integration is on the roadmap. Webhooks for external integrations too.
But the API is already complete. Everything I described above works today, on every plan. If you want to try it, create a free account at stringbase.io — 1 project, 1,000 keys, 5 languages, 5,000 AI translations per month. No credit card.
The API docs are at stringbase.io/docs. Two-column layout, code examples in curl, JavaScript, and Python.
Build something with it. I'd love to see what you automate first.