Creating a Bot

Three building blocks let your own service speak in your community. They work together: one integration can post a card, answer a /command, react to a button and update its own message.

The building blocks

• Webhooks: a URL that posts into a channel. Your service sends it JSON and the message appears under the name you gave the webhook. Made for alerts: CI results, monitoring, tickets.
• Triggers: your community's own slash commands. A member types /weather, mssgs sends the message to your web service, and what it answers appears in the channel as a card.
• Buttons: under a card, they open a link, change the card for everyone or run one of your triggers (see Bot Cards & Buttons).

Post your first message

BODY='{"content": "Build #1847 passed on main"}'
SIG=$(printf '%s' "$BODY" | openssl dgst -sha256 -hmac "$MSSGS_WEBHOOK_SECRET" | sed 's/^.* //')
curl -X POST "$MSSGS_WEBHOOK_URL" \
  -H "Content-Type: application/json" \
  -H "X-Mssgs-Signature: sha256=$SIG" \
  -d "$BODY"

Posting from GitHub? That needs no code: point a GitHub webhook at the URL and paste the secret into its Secret field. See integrations.

Add a slash command

Need longer? Answer straight away with a loader card and finish it through the callback_url in the request, which works for 30 minutes. The card shows your community's name, and its footer says who used which command.

A bot of its own

Want the bot to be its own member, with a name, avatar and BOT label? Create a bot account linked to your own account and manage it from the bot dashboard. With the desktop app signed in as the bot, an AI assistant can post cards with buttons through its MCP server.

Every field, response and error code is in the developer docs: webhooks, slash commands, message cards, buttons and live updates. And if you want AI-driven behavior without building anything, the MCP route might be all you need.