After the city’s “NOC-Alerts” Webex space was recreated, a hard-coded roomId in the flood-control bot started failing. What constructed flow should supply the destination for POST /messages?
Select an answer to reveal the explanation.
Short Explanation
Find the room’s current badge number before you mail the letter. List rooms, grab the id, then POST the message. Yesterday’s memorized roomId dies when the space is recreated.
Full Explanation
Webex roomIds are opaque identifiers that change when a space is deleted and recreated. After the city’s NOC-Alerts space was rebuilt, the flood-control bot must discover the current id—typically GET rooms filtered by title or type—then POST /messages with that roomId. Hard-coding yesterday’s id fails closed against a space that no longer exists under that identifier, so flood alerts never land.
Inventing a roomId from an MD5 of the space title is not how Webex assigns ids and will not address a real room. Omitting roomId so Webex supposedly delivers to every space the bot can see is not valid message construction. Reusing an old meeting SIP address as if it were a messages roomId confuses meetings addressing with the rooms and messages resource model. Prefer membership of the bot in the target space plus title filter over fragile global hard-codes. When recreation is common, store the looked-up roomId in config with a last-verified timestamp and re-resolve on POST failures that look like unknown room.
Exam caveat: treat roomId as lookup data, not forever config, whenever civic ops spaces can be recreated or renamed. Operational check: list rooms by the NOC-Alerts title, cache the returned id, POST a test message, and raise an alert if lookup returns empty so operators fix membership or naming before real flood events go silent.