Chat Platforms¶
Slack — shipped¶
Slack is this extension's first webhook provider adapter, live-verified end to end. It gets full chapters of its own rather than a recipe here: Slack Endpoints for the DBA side (app setup, the profile, response classification, operational notes) and Sending to Slack for the sender side (mrkdwn, the three formatting tiers up to raw Block Kit, threading).
One capability worth knowing arrived with pg_relay 1.2's body_merge: a Slack profile can pin its channel — "body_merge": {"channel": "C0XXXXXXX"} makes every message through that profile land in one channel regardless of what the sender passes, turning routing into a profile-owned guarantee rather than a producer courtesy. See the body_merge section.
Mattermost — assessed compatible; adapter unscheduled¶
Self-hosted, Slack-shaped, and the answer to a question no hosted provider can answer: notifications that keep working with no internet connection at all — PostgreSQL, the Processor, the Mattermost server, and the people reading it, all inside the LAN. The queue-as-buffer design pays off doubly here: if the chat server goes down, everything simply retries until it returns.
Two routes, both passing the fit test cleanly (pg_relay's chapter works both in full):
- Incoming webhook — the whole credential is the generated hook URL, so the URL itself is the
_env:secret and theauthblock is a placeholder. Simplest possible integration; no per-post message id. - REST API with a bot account (
POST /api/v4/posts, bearer token) — the closer mirror of the Slack adapter: a revocable token, and the created post'sidas the provider reference. This is the shape a future adapter would implement.
The formatting caveat that will matter to an adapter: Mattermost renders standard Markdown, not Slack mrkdwn, and has no Block Kit — *bold* means italics there. A shared renderer is a bug; the adapter needs its own.
Microsoft Teams — assessed compatible; adapter unscheduled¶
Reachable — with two eyes open. The classic Office 365 Connector webhooks are retired; the current mechanism is a Power Automate Workflow ("when a webhook request is received"), whose long logic.azure.com/...sig=... URL is the entire credential — same placeholder-auth, URL-as-secret pattern as Mattermost's hook. The payload is not negotiable: an Adaptive Card in a type: "message" envelope (a third dialect after mrkdwn and Markdown), and a 202 means the trigger accepted the request — the flow that actually posts can still fail afterwards, visible only in Power Automate's run history. There is no bot-token alternative within reach: Graph requires delegated permissions to post channel messages, which the client-credentials model deliberately can't hold.
Also worth knowing: a workflow is owned by the account that created it and dies with that account — create it from a service account. Full mechanics in pg_relay's chapter.
Choosing between them¶
| Slack | Mattermost | Teams | |
|---|---|---|---|
| Status here | Shipped adapter | Assessed | Assessed |
| Credential | Bot token (revocable) | Hook URL or bot token | Workflow URL only |
| Provider ref | Message ts |
Post id (API route) |
None |
| Text dialect | mrkdwn + Block Kit | Markdown | Adaptive Cards |
| Air-gap friendly | No | Yes | No |
| "Sent" means | Posted | Posted | Trigger accepted; post may still fail |
Next: SMS Providers.