If it can post JSON, it can post here

From the channel, if you may manage that channel. Creating one returns a URL and a secret, and the secret is shown exactly once. The credential travels in an Authorization header rather than in the URL, because a URL with a credential in it lands in every proxy access log between the caller and here.

• Requires the manage-channel permission on that channel, and nothing wider
• The secret is displayed once and stored only as a hash
• Sent as a bearer token in a header, never as a query string
• An unknown hook, a revoked hook and a wrong secret all answer the same 404
• Revoking a hook deactivates the bot behind it

Message text, a display name that overrides the bot’s own, an icon, and attachments with a title, a link, body text, fields and a footer. Attachments are flattened to plain text on the way in — a title on one line, its URL on the next for the linkifier to pick up, fields as name and value — because the message renderer shows what it is given rather than interpreting markup it did not write.

• text, username, icon and attachments, in the shape Slack established
• One hook can speak for several systems by setting a different username per post
• The room shows a webhook badge beside the name, so nobody mistakes it for a person
• Attachments flatten to readable plain text rather than arriving as raw markup
• A post over 8 KiB is truncated, because an alert at three in the morning must not be lost to a 422

Because the alternative is a second, weaker idea of who wrote a message. A hook’s posts are authored by a real account that is a real member of the room, which means the ordinary permission model decides whether the post is allowed, the ordinary audit trail records it, and removing the bot from the room does exactly what removing anybody from a room does.

• The author is an account, not a special case in the message table
• The channel’s permissions govern the hook, with nothing bolted on beside them
• Bot accounts are not counted as billable seats
• Deactivating the bot stops the hook at the next call

Rate limits are applied per organisation across classes of request rather than per endpoint, and they scale with the number of seats. Every rejection carries the headers a well-behaved client needs to back off correctly, so a system that respects them will not need supervision.

• Per-organisation budgets, scaled by seats, with a per-member ceiling
• A 429 carries RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset and Retry-After
• An empty payload is refused with 422 rather than posting an empty message