SAGARIS notifications in Slack, and what Slack cannot do back
Partly, and the half that is missing is the half people assume. SAGARIS delivers product notifications into a Slack channel you choose, using an incoming webhook or a bot token your admin pastes in. It is one-way: there is no SAGARIS app in Slack, no slash command, and no way to approve, reply or act from inside Slack. Anything a notification asks you to do is done in SAGARIS.
Connected. Delivery only, and in one direction. SAGARIS posts notifications into a channel you choose. There is no Slack app to install and nothing you can act on from inside Slack.
Last verified October 5, 2026. All integrations
What moves, and which way
An incoming-webhook URL or a bot token plus a default channel, supplied by your admin. Not an OAuth app.
- Into SAGARIS
- Nothing. SAGARIS holds no read access to your Slack workspace: it cannot see your channels, your messages or your members, and it does not receive anything you type. There is no Events API subscription and no interactivity handler, so a reply in the channel reaches nobody.
- Back into Slack
- Product notifications are posted into the channel you choose: the ones marked critical, action required or warning, which is the set worth interrupting somebody for. Routine activity is deliberately not sent, because a channel that fires on everything gets muted within a week and then the critical one is missed too.
- The boundary
- One direction only. There is no Slack app to install, no slash command and no approval you can grant from Slack, so a notification is a pointer back into SAGARIS rather than a place to act. The destination host is pinned to Slack when the credential is saved and checked again on every send, so a stored value that was later tampered with cannot be used to reach somewhere else. Your admin can rotate or remove the credential at any time, and revoking it at the Slack end stops delivery whatever we hold.
Setting up delivery
- 01
Create an incoming webhook, or a bot token, in your own Slack
This happens in your Slack workspace, under your own admin control. Nothing is installed from our side, and there is no consent screen naming us.
- 02
Paste it into Settings, with a default channel
An admin pastes either the incoming-webhook URL or the bot token plus the channel to post into. The value is stored as a workspace secret, rendered masked, and revealed only on an explicit action.
- 03
Choose the channel deliberately
Pick a channel the people who can act on a critical notification actually read. A firehose channel and an alerting channel are different things, and only the second one gets read on a Friday afternoon.
- 04
Rotate it when you need to
Rotating either credential is a paste into the same field. An empty submission means leave it unchanged rather than wipe it, so a masked round-trip cannot delete a working secret by accident.
If you need Slack to act on SAGARIS, not just hear from it
That is a real requirement and we do not meet it today. There is no approval button, no slash command and no message action, and no date is published for one. If an approval workflow in Slack is a hard requirement for your team, it is better to know that now than to discover it after an evaluation.
What exists in the meantime is the public REST API and outbound webhooks. A Slack app you build yourself can receive a SAGARIS webhook, post whatever shape of message you want into whatever channel you want, and call the REST API with a workspace key when somebody presses your own button. That path is documented and authenticated, and it is under your control rather than ours.
How we checked
Read from the code rather than from a probe, because there is no endpoint to probe: a one-way webhook has no connect route. The absence is the evidence. There is no Slack client id or secret in the codebase, no Events API subscription, no slash-command handler and no interactivity handler; src/lib/workspace-slack-config.ts stores only an incoming-webhook URL or a bot token and a default channel, and src/lib/notifications/slack-dispatch.ts posts to one or the other and re-validates the destination host at dispatch time.
Verified October 5, 2026. If this is out of date or wrong, email founders@sagaris.ai and we will correct it and move the date.
Slack and SAGARIS, the questions people actually ask
- MOST ASKED
No. You create an incoming webhook or a bot token in your own Slack and paste it into SAGARIS. Nothing is installed from our side and there is no consent screen naming us.
No. Delivery is one-way. A notification tells you something needs a decision and you make it in SAGARIS. There is no slash command, no message action and no interactivity handler, and no date is published for one.
No. There is no read access of any kind: no Events API subscription, no channel history, no member list. The credential you supply is a send path and nothing else.
The ones marked critical, action required or warning. Routine activity is deliberately excluded, because a channel that fires on everything gets muted and then the important one is missed as well.
The destination host is pinned to Slack when the credential is saved and checked again on every send. A stored row that predates the save guard, or one that was tampered with afterwards, still cannot be used to reach an arbitrary host.