Operators type /fail-over in a group Webex ops space without @mentioning the municipal bot. The bot’s messages:created webhook never fires for that traffic. Why?
Select an answer to reveal the explanation.
Short Explanation
In a crowded group room, the bot is not a silent stenographer—it only hears when called by name. You need to mention the bot in group ChatOps commands. A one-to-one space is the quieter exception.
Full Explanation
In group Webex spaces, bots are not silent stenographers: messages:created webhooks for the bot fire when the bot is mentioned, and listing as the bot typically requires mentionedPeople=me. Operators who type /fail-over in a municipal group ops space without an @mention therefore produce traffic the bot never hears, so the webhook path stays quiet. Direct one-to-one spaces behave differently and are the quieter exception for always-on commands. The claim that Webex disables all bots in group spaces unless an admin grants Meetings host role invents a Meetings privilege gate that is not the ChatOps mention rule. The idea that the bot must poll with mentionedPeople=everyone to see unmentioned group traffic misunderstands filters and reintroduces polling instead of fixing command design. The claim that authorization codes expire after one group message, so the webhook secret rotates away, is an identity myth unrelated to mention-scoped event delivery. Exam caveat: design group ChatOps commands to @mention the bot, or use a one-to-one space, so constructed webhooks actually fire. Operational check: post /fail-over without a mention and confirm no bot webhook; post the same command with @bot, confirm messages:created delivery, then document the mention requirement for operators.