> For the complete documentation index, see [llms.txt](https://docs.fylr.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.fylr.io/releases/2026/v6.34.5.md).

# Release v6.34.5 (2026-09-02)

Published 2026-09-02 12:14:47Z

* [fylr\_checksums.txt](https://s3.eu-central-1.wasabisys.com/fylr-releases/v6.34.5/fylr_checksums.txt)
* [fylr\_v6.34.5\_darwin\_amd64.tar.gz](https://s3.eu-central-1.wasabisys.com/fylr-releases/v6.34.5/fylr_v6.34.5_darwin_amd64.tar.gz)
* [fylr\_v6.34.5\_darwin\_arm64.tar.gz](https://s3.eu-central-1.wasabisys.com/fylr-releases/v6.34.5/fylr_v6.34.5_darwin_arm64.tar.gz)
* [fylr\_v6.34.5\_linux\_amd64.tar.gz](https://s3.eu-central-1.wasabisys.com/fylr-releases/v6.34.5/fylr_v6.34.5_linux_amd64.tar.gz)
* [fylr\_v6.34.5\_windows\_amd64.zip](https://s3.eu-central-1.wasabisys.com/fylr-releases/v6.34.5/fylr_v6.34.5_windows_amd64.zip)

## Server

### Important

* **A workflow webhook is handed a short-lived token now.** A webhook that sends the access token receives one minted for that call — issued in the name of the person who triggered the transition, valid for 15 minutes — instead of that person's session token. A receiver that stored the forwarded token and used it hours later has to call back while the transition is fresh. See the full note under **Fixed**.

### Fixed

* **A workflow webhook can call back into the API again**: a webhook that sends the access token — the *Send Authorization Header* option, or `api_user_access_token` in its payload — forwarded the token of the request that triggered it, and since 6.34.0 a session token is bound to the browser it was issued in. The webhook target replays that token server-side, without the browser's cookie, so every call back into the API was refused with `401 UserRequired` and a webhook pointing at a plugin extension of the same instance stopped working. The webhook now receives a token minted for it: unbound, issued for the acting user, and bounded by a 15 minute lifetime rather than by the revoke that ends a plugin callback — a webhook target is a foreign service and may do its work after it has answered. Server-side plugin callbacks (`db_pre_save`, transitions, extensions, collection uploads, exports) were switched to such tokens in 6.34.0; the webhook action was missed at the time, it was not deliberately left out. Webhooks triggered by an API client or the password grant kept working throughout — those tokens are unbound — so this affects transitions triggered by people in the web frontend. It also keeps a session token with its full lifetime (24 hours by default) from being sent to a freely configurable, possibly external URL. See [Workflow webhooks](https://docs.fylr.io/for-administrators/readme/workflow-webhooks) and [Session binding](https://docs.fylr.io/for-developers/api/endpoints/api-oauth2#session-binding-anti-hijacking). \[99c160d7c]
* **No access token in a URL fylr fetches from itself**: the images of a workflow e-mail and the thumbnails of an XLSX export are fetched by fylr over HTTP from its own API, and both put the caller's access token into the URL. What grants access there is the signature the file URL carries; the token rode along unused, and a URL with a token in it outlives the request it belongs to, in logs and in proxies. The e-mail image is fetched as it was rendered now, and the export thumbnail signs its own request instead of depending on how the URL was rendered. Instances see no difference in the mails and sheets they produce. \[d3644c45b]
* **A failed request no longer crashes while its error is rendered**: when a request failed before the server's cache was loaded, translating the error message into the user's language ran on a context carrying neither a session nor a base configuration, and reading the missing configuration panicked the handler. The language preferences fall back to the default configuration now, and a request whose client has already hung up skips the error rendering altogether — there is nobody left to read it. That is the case this was reported for: a proxy in front of fylr aborts requests that queue behind a cache reload, and each aborted one left a stack trace in the log. No request answered a client differently because of it, and no process died — the HTTP server catches a panic per connection — but a single reload could fill the log with traces. \[5070a945e]

### Docker images

```
docker.fylr.io/fylr/fylr:v6.34.5
docker.fylr.io/fylr/fylr-server:v6.34.5
```