Skip to content

Incoming webhooks

Post JSON from monitoring tools, CI or your own scripts into a channel. Each incoming webhook has a URL, a secret and a bot account governed by channel permissions. The payload follows Slack's format, so compatible tools can use the new URL.

Updated

Core · every plan

From JSON to message

What each field of the payload becomes

POST · Authorization: Bearer ••••

  1. "username": "Monitoring"
  2. "icon_url": "https://…/pager.png"
  3. "text": "p95 latency above 400 ms"
  4. "attachments": [{ "title": "api-eu-1" }]

# incidents

Monitoring webhook

p95 latency above 400 ms

api-eu-1, as plain text

Over 8 KiB? Truncated and posted, never rejected.

Created by
Anyone who may manage the channel
Credential
A bearer secret, shown once, sent in a header
Payload
Slack-shaped: text, username, icon, attachments
Author
A bot account provisioned with the hook

How it works

Create, post, stay within limits

  1. How do I create an incoming webhook?

    From the channel, if you may manage it. You get a URL and a secret, shown exactly once and stored only as a hash. The secret travels in an Authorization header, never in the URL, so it stays out of proxy logs.

  2. Why does a webhook need a bot account?

    Every post is authored by a real account that is a real member of the room. The room’s ordinary permissions decide whether the post is allowed, the audit trail records it, and removing the bot stops the hook. Bots are not billable seats.

  3. What are the rate limits?

    Per organisation, by class of request, scaled by seats. Every 429 carries RateLimit and Retry-After headers, so a client that respects them backs off on its own.

What it does not do

The edges, before you find them

  • Managed rooms only: the server cannot compose a message in an end-to-end encrypted room.
  • An incoming webhook only posts. Outgoing webhooks are a separate setting and carry identifiers, never content.
  • It cannot read history, list members, react or open a thread. Use a bot account for that.
  • Attachments render as plain text. No buttons, menus or forms.
  • The secret is a bearer token, not an HMAC signature. Treat URL and secret together as a credential.

FAQ

Incoming webhooks: questions

  • Yes. Anyone who may manage a channel can create an incoming webhook for it, which returns a URL and a bearer secret that any system able to post JSON can use. The payload format follows Slack’s shape, so most existing integrations need only a URL change.

  • In most cases yes. Enclessa accepts the Slack-shaped payload — text, username, icon and attachments — so a tool that already posts to Slack usually needs a new URL and a header carrying the secret. Interactive components are not supported, because Enclessa messages have no buttons or menus.

  • No. End-to-end encrypted rooms hold no server-side key, so the server cannot compose a message in one. Webhooks work in managed rooms, where the server can read and write message content.

Bring your team over this afternoon

Free for up to 10 people, with encrypted direct messages and video calls. No payment card, no time limit, no server to run.

For businesses and organisations only — not available to consumers.

Create your organisationCompare plans