Skip to content
Localeo

Changelog

Changes to the public API and to these docs, newest first. Anything that would break an existing integration is called out explicitly.

2026-08-28

Webhooks are documented. No endpoint, parameter or response body changed — webhooks are delivered to your server rather than requested from ours, so nothing here affects an existing integration with the API.

  • Webhooks describes the whole surface: the event envelope, the ten event types and the payload each one carries, the headers on every request, and what we treat as a failed delivery.
  • Signature verification is written down, including a snippet you can paste. Set a secret on the endpoint and check it: without one, any host that can reach your URL can post whatever it likes to it. The signature covers a timestamp as well as the body, so a captured request cannot be replayed later.
  • Endpoints must use https and be publicly reachable. The body carries your translation content, and a signature proves who sent it but does not conceal it. Testing against your own machine works through a tunnel such as ngrok, which gives you a public https URL.
  • Every attempt is recorded — the exact payload sent, your response status and body, how long it took, and what failed. Read it under Project → Integrations → View logs, where you can also redeliver a past event or send a test one.

2026-08-19

GET /releases now reports pagination metadata, and its pages are reliable. Additive: items is unchanged, so an integration reading only that keeps working.

  • Responses carry page_info — total_count, page, page_size and total_pages, the same shape the dashboard’s own API returns. Page until page reaches total_pages rather than probing for an empty page. See Pagination.
  • Drafts are excluded by the query, not after the fact. They were previously removed from each page once it had already been read from the database, so a page could come back short — or empty — while later pages still held published releases. A short page now means the last page. This also makes total_count meaningful: it counts only the published releases the endpoint can actually return.
  • A release whose creator was deleted is no longer hidden. The list joined the creating user, so deleting that account silently removed their releases from the response. Nothing about the payload changes; releases that had vanished simply reappear.

2026-08-03

Releases now report the languages they actually shipped. No endpoint, parameter or response body changed — the languages array has the same shape, and the values in it are now correct.

  • GET /releases/{release_id} no longer lists languages a release does not contain. It previously returned the project’s languages as they are now, so a language added after a release was published appeared in that release’s languages with download URLs that returned 404. It now returns the set captured when the release was published. If you were filtering the array by probing each URL, you can stop.
  • is_base_language is the base language as of publish, not as of now. Changing a project’s base language no longer relabels releases published before the change.
  • /r/latest/ drops languages the newest release does not ship. Previously a language removed from a project kept being served from latest indefinitely, with the previous release’s content, because publishing only overwrote files and never removed them. A hard-coded latest/{language} path for such a language now returns 404 instead of stale strings. Pinned release URLs are unaffected — they were always immutable.

2026-07-27

Documentation and response metadata. No endpoint, parameter or response body changed.

  • The API description moved to OpenAPI 3.1. The reference now documents every response header, declares the environment’s base URL as a selectable server, and carries realistic examples.
  • 429 responses are now JSON. They previously returned a plain-text Too Many Requests body, which was the only response that did not follow the documented {"error": "..."} shape. Clients matching on the body of a 429 should now expect {"error": "rate limit exceeded"}; clients branching on the status code — as recommended — are unaffected.
  • These developer docs were published at https://docs-dev.localeo.app.