Since Gotify 3.0.0 (released 2 days ago: https://github.com/gotify/server/releases/tag/v3.0.0), application tokens now use a significantly larger keyspace (see: gotify/server#939). A real token generated by a current Gotify instance is now approx. 50 characters, prefixed with "gtyfa.".
This new format of token is fully accepted by Gotify's own /message API, confirmed by sending it directly via curl, which returns a valid 200 response with the message delivered.
However, shoutrrr's gotify validation service (pkg/services/push/gotify/gotify_validation.go) hardcodes a fixed-length check that rejects this token outright before any request is made:
goTokenLength = 15
TokenChars = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789.-_"
Any client using this library against a Gotify 3.0.0+ instance with a freshly-generated token fails immediately even though the token is genuinely valid and the underlying server accepts it fine. Tested specifically with (your) Watchtower (v1.19.0) and Beszel (v0.18.7, https://github.com/henrygd/beszel). UptimeKuma did NOT face this issue, but worth noting that I didn't have to "craft" a URL for UptimeKuma like you do for Watchtower and Beszel, I just selected Gotify from a dropdown in the notifications section of UptimeKuma (I assume it is using a different Gotify API endpoint).
Can we change the validation to match the new Gotify token format/lengths - I guess with the ability to accept older/legacy gotify token lengths as well?
Disclaimer - I am not a developer, so very unlikely I can put together a PR for this, Claude helped me troubleshoot the issue in my lab, but this issue is very much my words.
Since Gotify 3.0.0 (released 2 days ago: https://github.com/gotify/server/releases/tag/v3.0.0), application tokens now use a significantly larger keyspace (see: gotify/server#939). A real token generated by a current Gotify instance is now approx. 50 characters, prefixed with "gtyfa.".
This new format of token is fully accepted by Gotify's own /message API, confirmed by sending it directly via curl, which returns a valid 200 response with the message delivered.
However, shoutrrr's gotify validation service (pkg/services/push/gotify/gotify_validation.go) hardcodes a fixed-length check that rejects this token outright before any request is made:
Any client using this library against a Gotify 3.0.0+ instance with a freshly-generated token fails immediately even though the token is genuinely valid and the underlying server accepts it fine. Tested specifically with (your) Watchtower (v1.19.0) and Beszel (v0.18.7, https://github.com/henrygd/beszel). UptimeKuma did NOT face this issue, but worth noting that I didn't have to "craft" a URL for UptimeKuma like you do for Watchtower and Beszel, I just selected Gotify from a dropdown in the notifications section of UptimeKuma (I assume it is using a different Gotify API endpoint).
Can we change the validation to match the new Gotify token format/lengths - I guess with the ability to accept older/legacy gotify token lengths as well?
Disclaimer - I am not a developer, so very unlikely I can put together a PR for this, Claude helped me troubleshoot the issue in my lab, but this issue is very much my words.