Messaging Integrations: Slack, Discord, and Webhooks

Hermes Everywhere You Already Work

The messaging gateway is one of Hermes's most practically powerful features: it lets the agent live inside the tools your team already uses. Instead of opening the Desktop app or a terminal to talk to Hermes, you send it a Slack message. Instead of managing a separate interface, your team interacts with the agent in the same Discord server where you already coordinate. Webhooks extend this further, letting any system that can make an HTTP request trigger the Hermes agent automatically.

The gateway connects to 20+ messaging platforms in a single background process: Telegram, Discord, Slack, Google Chat, WhatsApp, Signal, SMS, Email, Home Assistant, Mattermost, Matrix, Microsoft Teams, LINE, and more. Each platform is a separate adapter that translates incoming messages into Hermes sessions and routes responses back out. You configure which platforms to connect to, and the gateway handles the protocol differences invisibly.

The Desktop app surfaces the gateway's configuration and monitoring in a dedicated panel, making it practical to manage messaging integrations without touching the CLI.

Initial Setup: hermes gateway setup

The easiest way to configure your first messaging integration is the interactive setup wizard:

hermes gateway setup

This launches an interactive CLI wizard (even if you are primarily a Desktop user, the initial setup happens in the terminal). Arrow keys navigate the platform list; selecting a platform walks you through that platform's specific requirements: creating a bot user, obtaining credentials, and configuring the connection.

Each platform's setup is different. Discord requires creating a bot application in the Discord Developer Portal and adding it to your server. Slack requires creating a Slack app and installing it to your workspace. Webhooks require generating an endpoint URL that the gateway provides and registering it with the service you want to trigger Hermes from.

The wizard handles the Hermes side of the setup -- creating the channel configuration in gateway.json. The platform side (creating the bot, obtaining API credentials) requires actions in each platform's developer console. The wizard provides instructions and links for each step.

The Security Default: Allowlisting Users

By default, the gateway denies all incoming messages from users who are not on an explicit allowlist. This security default prevents your Hermes instance from responding to anyone who can find or guess the bot's address.

There are two ways to authorize users:

Environment variable allowlisting. Add user IDs to an environment variable in your .env file (the specific variable name depends on the platform: DISCORD_ALLOWED_USERS, SLACK_ALLOWED_USERS, etc.). Users in this list are always authorized.

DM pairing. A new user can pair with the gateway by sending a direct message with a one-time pairing code. The gateway generates pairing codes that you can distribute to users you want to authorize. Once paired, the user is added to the allowlist automatically and can use the gateway from that point forward.

For small teams, environment variable allowlisting is simpler. For larger deployments where you want to let users self-authorize, DM pairing scales better.

Session Management for Gateway Channels

Each messaging channel gets its own Hermes session that persists by default. When someone sends a message to the bot, it goes into the channel's session. When they send another message later, it continues the same session -- the agent has the full context of the previous conversation.

This persistence is usually what you want: a team's Slack bot that remembers what was discussed earlier in a project is more useful than one that starts fresh every message. But for some use cases, you want sessions to reset automatically.

Three auto-reset policies are available in gateway.json:

• idle. Reset the session after N minutes of inactivity. Useful for support bots where each conversation is a separate ticket and old context should not bleed into new inquiries.
• daily. Reset the session at a specific hour each day. Useful for daily standup bots or report generators that should start fresh each morning.
• both. Reset on whichever trigger fires first. The most aggressive option, suitable for high-traffic channels where context accumulation could slow responses.

Users can also manually reset the session at any time by sending /reset in the chat.

In-Chat Commands

The gateway supports a set of slash commands that work in any connected messaging platform, giving users control over the agent without leaving their chat interface:

• /new starts a new session (equivalent to /reset)
• /model gpt-4o switches the model for the current session
• /personality adjusts the agent's tone or persona for the session
• /retry re-runs the previous prompt (useful if the agent gave a poor response)
• /background spawns an isolated background subagent for a long-running task
• /voice switches the response to voice mode (if voice is configured)
• /status reports the current session status and active model

Skill invocation also works through messaging: if you have a skill named summarize, typing /summarize in a connected chat invokes it. This means your full skills library is available to any team member using the messaging interface, without them needing to know the underlying skill invocation syntax.

The Desktop Gateway Panel

The Gateway panel in the Desktop app (accessible from the left sidebar) provides a visual interface for the gateway's status and configuration. It shows:

• All configured platform connections with their current status (connected, disconnected, error)
• Recent message activity per channel
• Active sessions per channel
• Error logs for failed connections or message delivery failures

From the panel, you can enable or disable specific platform connections without stopping the entire gateway, view the connection configuration for each platform, and trigger a reconnection attempt when a platform shows as disconnected.

The Desktop panel does not yet provide a full form-based UI for initial gateway configuration -- that still happens via hermes gateway setup in the terminal. But for day-to-day monitoring and management of an already-configured gateway, the Desktop panel is sufficient for most tasks and significantly more convenient than running CLI status commands.

Webhooks: Hermes as an Automation Target

The webhook adapter is distinct from the real-time messaging adapters. Instead of maintaining a persistent connection to a platform, the webhook adapter listens for incoming HTTP POST requests and processes them as Hermes prompts.

Any system that can make an HTTP POST -- CI/CD pipelines, monitoring systems, GitHub Actions, Zapier, n8n, or any custom script -- can trigger the Hermes agent via webhook. The agent processes the webhook payload and can respond by posting a message to a configured channel, writing to a file, or taking any other action its tools support.

Webhook payloads are validated using standard signature verification (GitHub's X-Hub-Signature-256 for GitHub webhooks, a generic V2 scheme with timestamp headers for others). This prevents malicious actors from sending forged webhook events to your Hermes instance.

The webhook adapter supports synchronous response: the HTTP POST returns 200 OK once the agent's response has been delivered to its configured destination, or 502 if delivery failed. This lets the calling system handle failures and retry intelligently rather than fire-and-forget.