Gitter Runs on Matrix Now: What That Changes for Your Bots and Clients

If your team has a chatops bot posting CI results into a Gitter room using a token you generated years ago, there's a decent chance that integration is built on assumptions that no longer hold. Gitter was acquired by Element (formerly New Vector) in 2020 and rebuilt so that Gitter rooms are backed by the Matrix protocol. The useful takeaway: a Gitter room is now, fundamentally, a Matrix room — and that changes how you should pick clients and write integrations.

What "Gitter on Matrix" actually means

Matrix is an open protocol for federated real-time communication. Instead of messages living in a proprietary Gitter backend, each Gitter room is implemented as a room on a Matrix homeserver, with a room alias (a human-readable address like #project:gitter.im) that any Matrix-speaking client can resolve and join.

Two practical consequences follow:

• Client choice widened. You are no longer limited to the Gitter web or mobile apps. Any Matrix client — Element being the obvious one — can join the same room by alias and see the same conversation.
• The integration surface moved. The classic Gitter REST and streaming APIs predate the migration. The durable, future-proof way to automate a Gitter room is now the Matrix Client-Server API, because that's the protocol the room actually speaks.

Choosing a client: Gitter web app vs. a Matrix client

For humans, the decision is mostly about workflow, not capability:

• The Gitter web app is tuned for open-source community rooms: discovery tied to GitHub organizations, a low-friction "browse a project, jump into its chat" experience. If your room exists to serve a public repo's community, this is still the most natural front door.
• A Matrix client like Element makes more sense if your team already lives in Matrix for internal chat. Joining the Gitter-backed room by alias puts the community room in the same client as your private ops rooms — one notification stream, one search box, consistent end-to-end encryption settings where applicable.

Be aware that behavior is not guaranteed to be pixel-identical across clients. Message history depth, media rendering, and threading can differ between the Gitter UI and a generic Matrix client, and federation behavior depends on homeserver configuration. Treat "it works in Element" and "it works in the Gitter app" as two claims to verify, not one.

A worked example: a CI notification bot over the Matrix API

Say you want a GitHub Actions job to post build results into your project's Gitter room. The legacy approach was a Gitter API token and a POST to a Gitter-specific endpoint. The migration-era approach is a dedicated bot account on the Matrix homeserver, using the standard Client-Server API.

The flow, run from any machine with network access to the homeserver (no special permissions beyond the bot account's credentials):

# 1. Log in the bot account to get an access token
curl -XPOST https://matrix.org/_matrix/client/v3/login \
  -H 'Content-Type: application/json' \
  -d '{"type":"m.login.password","user":"your-ci-bot","password":"BOT_PASSWORD"}'

# 2. Resolve the Gitter room alias to a room ID
curl "https://matrix.org/_matrix/client/v3/directory/room/%23yourproject%3Agitter.im"

# 3. Send the notification (bot must have joined the room first)
curl -XPUT "https://matrix.org/_matrix/client/v3/rooms/ROOM_ID/send/m.room.message/TXN_ID" \
  -H "Authorization: Bearer ACCESS_TOKEN" \
  -d '{"msgtype":"m.text","body":"Build #482 passed: https://ci.example.com/482"}'

Notes and risks: the homeserver domain in these examples is illustrative — check which homeserver actually serves your room's alias before scripting against it. TXN_ID is a client-chosen unique string per message; reusing it makes retries idempotent, which matters for flaky CI networks. Never commit the bot password or token; pass them via your CI system's secret store. And don't assume the exact endpoint versions above are current — verify against the Matrix Client-Server spec version your homeserver advertises.

Expected check: after step 3, the message should appear in the room when viewed from both the Gitter web app and a Matrix client. If it appears in one but not the other, you have a federation or membership problem (usually: the bot didn't actually join the room, or the alias resolved to a different room than you think).

The trade-off you should accept up front

The honest limitation is drift. The standalone Gitter apps' feature set relative to Element has shifted over time, legacy Gitter API tokens and endpoints may be deprecated or rate-limited differently than older tutorials claim, and identity moved from GitHub/Twitter OAuth toward Matrix IDs — which affects how scripts authenticate and how mentions render. Anything you read in a pre-2021 Gitter integration guide should be treated as a hypothesis, not documentation.

That uncertainty is also the argument for the Matrix path: targeting the open protocol means your bot's API surface is maintained by a broad ecosystem rather than by the fate of one app's legacy endpoints.

What to do this week

1. Create a throwaway test room and confirm it's joinable from both the Gitter web app and a Matrix client via the room alias.
2. Send messages from each side and verify bidirectional delivery, plus how notifications and mentions behave for your team.
3. Run your existing bot's auth flow end-to-end. If it depends on legacy Gitter endpoints, plan the migration to a Matrix bot account before it breaks, not after.
4. Check the current official Gitter and Element announcements for the status of the standalone apps and supported integration paths — this is the piece most likely to have changed since any guide was written.

The mental model that survives all of this churn is simple: Gitter is a community-focused interface; Matrix is the room's actual address and protocol. Build for the protocol, and pick whichever interface your humans prefer.