Refer to the exhibit. A webhook has been created so that an application is notified when users mention a bot in a Webex Teams space. The exhibit shows an example of a notification received by the…

Question

Exhibits

Options

• Aif ((notification.resource == 'notifier') && (notification.event == 'created')) { webex.messages.get(notification.data.id).then( msg => console.log(msg.text)); }}
• Bif ((notification.resource == 'messages') && (notification.event == 'created')) { webex.messages.get(notification.data.id).then( msg => console.log(msg.text)); }
• Cif ((notification.resource == 'messages') && (notification.event == 'created')) { if (notification.data.personId != BOT_ID) { webex.messages.get(notification.data.id).then( msg => console.log(msg.text)); }}}
• Dif ((notification.resource == 'notifier') && (notification.event == 'created') && if (notification.data.personId !== BOT_ID) { webex.messages.get(notification.data.id).then( msg => console.log(msg.text)); }}

• A
  6% (2)
• B
  79% (27)
• C
  3% (1)
• D
  12% (4)

Explanation

When Webex fires a webhook for a new message in a space, the notification payload will have resource set to 'messages' and event set to 'created'. Option B is correct because it checks both of these fields accurately before calling webex.messages.get(notification.data.id) to retrieve the full message and log it.

Option A and D are wrong because they check for resource == 'notifier', which is not a valid Webex webhook resource type for message events.

Option C uses the correct resource and event check but adds an unnecessary personId != BOT_ID guard. The webhook is already scoped to fire only when other users mention the bot, so this extra filter is redundant - and, more importantly, the question only asks to print the messages, not to avoid bot-to-bot loops. Option B handles the requirement cleanly without over-engineering the filter.

No community discussion yet for this question.