I’ve been building a Trello integration on top of my automation project and something I’m missing is the possibility to easily subscribe to board updates over websocket. The provided webhook interface is great, but it requires a callback URL hosted on a machine with an IP address reachable from the Trello servers. For the sake of flexibility and easier integration, it’d be great to have a websocket interface as well, similar to what’s provided by Todoist. A client would open a connection to a private token-authorized websocket server and updates would be streamed there in the same format they’re currently provided to the webhooks. Such a mechanism would remove much of the security/management burden required by webhooks, and it’d also allow local machines without a public IP addresses (like a RaspberryPi connected to a home network) to subscribe to Trello updates.
Thanks for the feedback, @FabioManganiello. The Trello web client uses websockets to remain synced and up-to-date with changes occurring in the backend, so it is something that we’re familiar with. Although it isn’t something that is officially supported nor documented it might be worth checking out what the Trello web client is doing and seeing if you can subscribe to the same websockets it is using.
I’ll pass this along to the team so that they know there is interest in a publicly available and supported websockets interface.
Thanks for the reply! I’ve managed to get some insights on the protocol by debugging the connection on
wss://trello.com/1/Session/socket?token=<token>. However, when I try to use my own long-lived token I get an
unauthorized error. At first glance, it looks that the token follows the format
<board_id>/<token>. Is that actually the case? That’d be quite unpractical - I’d have to open as many websocket connections as the number of boards that I want to subscribe.
That sounds correct as the web client only ever has a single board open at a time. So only needs to receive updates regarding a single board.
At a closer look it seems that the format is actually
<user_id>/<token>. However, I’ve tried both the combinations
<token> is a long-lived token I previously got from
/authorize: neither of them works (still
unauthorized when I send a board subscription request). Things work instead if I use the token used by an active web client session. Are those different types of token? The token provided by the API is a shorter hex-encoded token, while the one used by the web client is longer and base64-encoded.
Asking more about this internally and have found that the only types of tokens currently supported are those from active web client sessions, unfortunately.
Would it be possible to extend it to API tokens? It sounds like a relatively low-hanging fruit to me, and since the format of the messages returned by the websocket interface is quite straightforward, it’d make interaction much simpler.
I’m talking with folks now to see how feasible it is for us to extend and support this. Once I hear more, I’ll let you know.