added
The deploy-key model, where the bearer token IS the project. It is what the CLI and the GitHub Action both run on.
api v1 · current
The API changelog.
Nothing removed.
/v1 only ever gains things. New endpoints and new response fields land inside the same prefix, and a field you already parse never changes shape or disappears. A breaking change would ship under a new version prefix, which is reserved and still empty.
v1/v1
the only prefix in use
the only prefix in use
5 releases
11 changes, none of them breaking
the shape of the log
One version prefix, no removals.
Three of these four are properties of this log itself. The fourth is the size of the webhook catalog the API serves.
5
releases on /v1, every one of them additive
1
version prefix in use. The next one is reserved and empty
0
breaking changes since the API shipped
12
signed webhook events. The catalog is at GET /v1/webhooks/events
dated by release, not by semver
use the arrow keys to travel
2026-07-08
CDN delivery, usage and the playground
July 8, 2026 · 4 changes
05 / 05
added
/v1/incontext/translations, /screenshots and /suggest drive the visual editor, with CORS scoped to that prefix and nothing else.
POST /v1/incontext/session exchanges a publishable key and an Origin for a scoped session token.
improved
A bilingual export now reports what it could not round-trip instead of silently substituting source text. Existing fields are unchanged, which is the whole point of putting it in a header.
GET /v1/pull gained the X-Skipped-Keys and X-Missing-Source-Keys response headers.
added
Plus /v1/glossary/import, /export and /extract, so a term base can be moved in and out without opening the console.
Full term-base CRUD over the API: GET, POST, PUT and DELETE on /v1/glossary.
added
Findings land on the translation rows you already pull, so nothing new has to be polled.
POST /v1/qa/run triggers an agentic quality pass and returns the run handle.
added
Subscribe per endpoint. Twelve typed events today, and GET /v1/webhooks/events returns the catalog with a sample payload for each one.
Signed webhooks emit key, translation, language, glossary and QA events alongside the original batch pair.
improved
The delivery carries a count and up to twenty samples rather than one call per changed row. Delivery logs record every attempt with the time of the next retry.
High-frequency events like translation.updated are coalesced into one delivery a window, so a bulk edit never floods an endpoint.
added
It returns an ETag and a short-lived cache and honours If-None-Match with a 304. The immutable sibling under /v{n} is content addressed and cached for a year.
A public, edge-cacheable GET /v1/cdn/{project}/{locale} serves your published strings.
added
Trigger it in CI with POST /v1/cdn/publish, and authorise reads with a dedicated read-only key in the X-Transglot-Cdn-Key header. Safe to put behind a CDN of your own.
Publishing promotes the current translations to a new immutable version, manually or on every push.
added
No request bodies are stored. It is a count and nothing else.
Every authenticated /v1 call is counted per token per day, and surfaced on the deploy hub.
improved
Project, pull, batches and glossary export. No request or response shape changed to make it work.
The deploy hub gained an API playground that runs read-only endpoints live against your project.
deprecation register
Nothing is going away.
One row per published surface, with the release that shipped it. The last column is the one to watch: a removal would appear there with a date on it long before it happened.
| Surface | Shipped | Status | Removal date |
|---|---|---|---|
GET /v1/project · /pull · POST /push · /translate · GET /batches | April 2, 2026 | current | none scheduled |
POST /v1/incontext/session · /translations · /screenshots · /suggest | May 20, 2026 | current | none scheduled |
GET, POST, PUT, DELETE /v1/glossary · /import · /export · /extract | June 12, 2026 | current | none scheduled |
POST /v1/qa/run | June 12, 2026 | current | none scheduled |
Signed webhook events, twelve typed cases | June 30, 2026 | current | none scheduled |
GET /v1/cdn/{project}/{locale} · POST /v1/cdn/publish | July 8, 2026 | current | none scheduled |
A row is never deleted from this table. If a surface is retired it keeps its row and gains a date, because a removal you can plan against is the whole point of publishing one.
the compatibility promise
Three rules you can build on.
additive
New endpoints and new response fields ship inside /v1. A field you already parse does not change shape and does not disappear.
new prefix
A breaking change would ship under a new version prefix rather than inside this one. That prefix is reserved and unused, and every release above landed on v1.
honest headers
When a pull cannot round-trip something it says so in a header. X-Skipped-Keys and X-Missing-Source-Keys were added rather than changing the body under you.
FAQs
What developers ask about API versioning and deprecation.
Is the Transglot API versioned?
Yes, by URL prefix. Everything published so far lives under /v1, which is the only prefix in use. There is no version header, no date pinning and nothing to configure.
Will an update ever break my integration?
Not inside /v1. New endpoints and new response fields are added, but a field you already parse does not change shape and does not disappear. If a change ever cannot be made additively it goes under a new prefix, and the old one keeps working.
Has anything been deprecated or removed?
Nothing, and the register above says so row by row. Every published surface is listed with the release that shipped it and a removal column that currently reads "none scheduled" all the way down.
How much notice would a removal get?
A removal would appear in that register with a date on it long before it happened, and the row would stay in the table afterwards rather than vanishing. A date you can plan against is the entire point of publishing one.
How do I know when something new ships?
Every release is dated on this page. The product changelog covers everything else that ships, and the console shows a marker when there is something you have not read.
Why is there a separate changelog for the API?
Because the API carries a compatibility promise that a product release does not. A developer checking whether an integration still works should not have to scroll past feature work to find out.
How do I add the API to my plan?
A bearer token starts on the Starter plan at $19 a month. Free covers the console but cannot mint a token, and the CLI, the GitHub Action, webhooks and MCP all sit behind that same token.
Where is the reference for the endpoints themselves?
On the API page: authentication, the endpoints, the rate limit, the file formats and the webhook catalog. This page is only the record of what changed and when.
works with what you already run
41 connectors, already built.
WordPress
Contentful
Sanity
Storyblok
Webflow
Strapi
DatoCMSHGHygraph
DrupalKOKontent.ai
Contentstack
Prismic
ShopifyWCWooCommerceWordPressContentfulSanityStoryblokWebflowStrapiDatoCMSHGHygraphDrupalKOKontent.aiContentstackPrismicShopifyWCWooCommerce
Magento
PrestaShop
BigCommerce
Intercom
Zendesk GuideFDFreshdesk
Help Scout
HubSpot
Notion
Confluence
Ghost
MailchimpKLKlaviyo
FigmaMagentoPrestaShopBigCommerceIntercomZendesk GuideFDFreshdeskHelp ScoutHubSpotNotionConfluenceGhostMailchimpKLKlaviyoFigma
Sketch
Adobe XD
GitHub
GitLab
Bitbucket
Azure Repos
JiraAUZapier, Make and n8n
App Store Connect
Google Play
Google Drive
Dropbox
Amazon S3SketchAdobe XDGitHubGitLabBitbucketAzure ReposJiraAUZapier, Make and n8nApp Store ConnectGoogle PlayGoogle DriveDropboxAmazon S3the contract is the product
Build on an API that does not move.
The API is on Starter and above. Free is $0 with 100,000 words to start, 10,000 a month after, and no API or webhooks.