# Twilio WhatsApp Alarm Notifications Acknowledgement

**URL:** <https://forum.inductiveautomation.com/t/twilio-whatsapp-alarm-notifications-acknowledgement/115795>\
**Category:** Ignition\
**Created:** [June 1, 2026, 8:09pm UTC](https://forum.inductiveautomation.com/t/twilio-whatsapp-alarm-notifications-acknowledgement/115795 "2026-06-01T20:09:58Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![Asjal\_Ahmad](https://avatars.discourse-cdn.com/v4/letter/a/9e8a1a/32.png) [@Asjal\_Ahmad](https://forum.inductiveautomation.com/u/Asjal_Ahmad)\
**Post date:** [June 1, 2026, 8:09pm UTC](https://forum.inductiveautomation.com/t/twilio-whatsapp-alarm-notifications-acknowledgement/115795/1 "2026-06-01T20:09:58Z")

</div>

I am setting up Ignition 8.3 alarm notifications using Twilio WhatsApp and have outbound WhatsApp template messaging working, but I am trying to understand how acknowledgement is supposed to work with WhatsApp templates.

The issue is that the WhatsApp template message does not include the usual Ignition alarm acknowledgement instruction, such as:

```python
Type 12345 to acknowledge this alarm.

```

With normal SMS alarm notifications, Ignition includes an acknowledgement code so the operator can reply and acknowledge the alarm. However, in the WhatsApp notification block I don't see a way to do that.

I do have this setting enabled in the Alarm Notification Profiles page

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/2/c/2cbcd2258820cf02653739e642705fb369a5dafc.png)

Any guidance from users who have implemented Ignition alarm acknowledgement over Twilio WhatsApp would be appreciated.

---

<div class="post-metadata">

**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\
**Post date:** [June 1, 2026, 9:19pm UTC](https://forum.inductiveautomation.com/t/twilio-whatsapp-alarm-notifications-acknowledgement/115795/2 "2026-06-01T21:19:00Z")

</div>

Have you explicitly configured the inbound settings on your defined Twilio acount?

> **[Inbound​ - Twilio Notification Profiles | Ignition User Manual](https://www.docs.inductiveautomation.com/docs/8.3/ignition-modules/alarm-notification/notification-profile-types/twilio-notification-profiles#inbound)**
>
> With the Twilio Notification module installed, you can configure notification profiles for your Twilio account to send SMS or voice notifications. SMS scripts for alarm notifications can be sent through Twilio's SMS messaging services or Twilio's...

---

<div class="post-metadata">

**Author:** ![Asjal\_Ahmad](https://avatars.discourse-cdn.com/v4/letter/a/9e8a1a/32.png) [@Asjal\_Ahmad](https://forum.inductiveautomation.com/u/Asjal_Ahmad)\
**Post date:** [June 1, 2026, 11:03pm UTC](https://forum.inductiveautomation.com/t/twilio-whatsapp-alarm-notifications-acknowledgement/115795/3 "2026-06-01T23:03:41Z")

</div>

I have a Twilio Connection configured with inbound settings. SMS and WhatsApp both use the same connection, and both profiles have alarm acknowledgement enabled.

SMS works correctly and includes the ACK code:

```python
To acknowledge, reply '149228'.

```

WhatsApp sends successfully through an approved Twilio Content Template, but the received message is only the exact template body:

```python
This is a test alarm for Ignition; reply for alarm details

```

It does not include the generated ACK code.

Is Ignition supposed to append the ACK code to WhatsApp template messages, like it does for SMS?

Screenshots attached show SMS with the ACK code and WhatsApp without it.

SMS:

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/7/5/755363ecb2e647748d57890fc634510ceb833306.png)

WhatsApp:

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/e/a/eaab1dd8639e4b88765146be572786ce3ae6424a.jpeg)

---

<div class="post-metadata">

**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\
**Post date:** [June 1, 2026, 11:27pm UTC](https://forum.inductiveautomation.com/t/twilio-whatsapp-alarm-notifications-acknowledgement/115795/4 "2026-06-01T23:27:12Z")

</div>

Per the code, yes, both Twilio SMS and Twilio WhatsApp follow the exact same branch of logic.  
The only conditions are whether there are unacknowledged events and whether the profile allows acknowledgement:

```java
    List<AlarmEvent> events =
        notificationContext.getAlarmEvents().stream().filter(alm -> !alm.isAcked()).toList();

    if (Boolean.TRUE.equals(isAckAllowed) && !events.isEmpty()) {
      String ackCode = ackManager.registerAlarms(notificationContext.getUser(), events);

      message += String.format("%nTo acknowledge, reply '%s'.", ackCode);
    }
    return message;

```

I have no idea what's up with 'Twilio Content templates'/whatsapp templates (I'm just reading this code, I didn't have anything to do with this feature's implementation). If you enable auditing (by specifying an audit log in the notification profile settings), does the log for the WhatsApp outbound have the acknowledgement prompt in it?

---

<div class="post-metadata">

**Author:** ![Asjal\_Ahmad](https://avatars.discourse-cdn.com/v4/letter/a/9e8a1a/32.png) [@Asjal\_Ahmad](https://forum.inductiveautomation.com/u/Asjal_Ahmad)\
**Post date:** [June 2, 2026, 2:08pm UTC](https://forum.inductiveautomation.com/t/twilio-whatsapp-alarm-notifications-acknowledgement/115795/5 "2026-06-02T14:08:54Z")

</div>

I did some more testing and narrowed it down further.

The Twilio Connection inbound settings are configured, and SMS ACK works correctly through the same Twilio Connection (SMS not WhatsApp).

For WhatsApp, Ignition does generate the ACK code internally. The Ignition alarm audit log shows:

action: "WhatsApp sent"  
actionValue: "Hello\nTo acknowledge, reply '167462'."  
actor: "+1xxxx"  
originatingSystem: "notificationProfile:Whatsapp\_Test"

However, the actual WhatsApp message received on the phone is still only the approved Twilio Content Template body, not the generated actionValue.

I then replied from WhatsApp with the exact ACK code:

167462

Twilio logs show the inbound WhatsApp reply was received successfully:

From: whatsapp:+1xxxx `(user phone number)`  
To: whatsapp:+1xxxx `(whatsapp sender)`  
Body: 167462  
TwiML Fetch Succeeded  
Message Received

There are no Twilio webhook errors now, but Ignition does not acknowledge the alarm, and no acknowledgement entry appears in the Ignition audit log.

I also tested changing the Messaging Service inbound behavior from “Defer to sender’s webhook” to “Send a webhook”; the result was the same.

So it looks like:

1. Ignition generates the WhatsApp ACK code.
2. Twilio receives the WhatsApp reply.
3. Twilio successfully invokes the inbound handler.
4. Ignition does not process/match the WhatsApp ACK reply.

Could this be related to WhatsApp inbound replies using `whatsapp:+number` in the From/To fields, while SMS uses plain E.164 numbers? Or is WhatsApp outbound supported, but inbound alarm acknowledgement not currently supported the same way SMS acknowledgement is?

---

<div class="post-metadata">

**Author:** ![Asjal\_Ahmad](https://avatars.discourse-cdn.com/v4/letter/a/9e8a1a/32.png) [@Asjal\_Ahmad](https://forum.inductiveautomation.com/u/Asjal_Ahmad)\
**Post date:** [June 2, 2026, 2:19pm UTC](https://forum.inductiveautomation.com/t/twilio-whatsapp-alarm-notifications-acknowledgement/115795/6 "2026-06-02T14:19:56Z")

</div>

Additional update:

I also tested the Ignition user contact value both ways:

Whatsapp contact = +1xxxx  
Whatsapp contact = whatsapp:+1xxxx

The WhatsApp notification was sent successfully in both cases, so two notifications but with the same generated ACK code. However, replying with the generated ACK code still did not acknowledge the alarm.

So the contact value does not appear to be the issue. Outbound WhatsApp notification works either way.

Current narrowed behavior:

- SMS profile works and ACK replies acknowledge the alarm.
- WhatsApp profile sends successfully.
- Ignition audit log shows it generates the WhatsApp ACK code:  
actionValue: "Hello\nTo acknowledge, reply '167462'."
- I reply from WhatsApp with exactly that code.
- Twilio shows the inbound WhatsApp message was received:  
From: whatsapp:+1xxxx  
To: whatsapp:+1xxxx  
Body: 167462  
TwiML Fetch Succeeded  
Message Received
- Ignition does not acknowledge the alarm and no ACK audit entry appears.

Changing the user contact value to include or exclude the `whatsapp:` prefix made no difference.

---

<div class="post-metadata">

**Author:** ![Dutch\_Buckholz](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/dutch_buckholz/32/55926_2.png) [@Dutch\_Buckholz](https://forum.inductiveautomation.com/u/Dutch_Buckholz)\
**Post date:** [June 2, 2026, 4:41pm UTC](https://forum.inductiveautomation.com/t/twilio-whatsapp-alarm-notifications-acknowledgement/115795/7 "2026-06-02T16:41:45Z")

</div>

Two more references for this that might be helpful, one in the docs:

[Twilio WhatsApp Notification](https://www.docs.inductiveautomation.com/docs/8.3/ignition-modules/alarm-notification/notification-profile-types/twilio-notification-profiles/twilio-whatsapp-notification#whatsapp)

One from IU:

[WhatsApp Twilio Settings Review](https://inductiveuniversity.com/video/whatsapp-twilio-settings-review/8.3?r=%2Fvideo%2Fsearch%2F%3Fq%3Dwhatsapp%26checked_topics%3D)

There's quite a few things that could be off, the most likely being any of multiple locations in Twilio that define the webhook ("Defer to sender’s webhook" with Inbound → Public Hostname defined on the gateway or explicitly provide an ip/dns w/ path e.g. `https://yourdomain:yourport/data/twilio/whatsapp`)

The general message flow should be:

1. Ignition sends the template message (the invitation to join a secure messaging channel)
2. User responds with anything to join the secure messaging channel
3. Ignition sends the free form message, this should be what includes the ack code
4. User responds w/ ack code if desired

If step 2 gets through to the gateway there's no reason that 4 wouldn't also, in which case you probably should contact support so we can get some log details for more detailed digging on our end.

If you pushed the generated ack code as parameter in step 1 though, the ack code response isn't likely to do anything more than trigger the sending of the free form message in step 3.

I would double check the Inbound → Public Hostname setting of the gateway, the service webhook, the Twiml App webhook, and if it still doesn't work reach out to support for more direct troubleshooting.

---

<div class="post-metadata">

**Author:** ![Asjal\_Ahmad](https://avatars.discourse-cdn.com/v4/letter/a/9e8a1a/32.png) [@Asjal\_Ahmad](https://forum.inductiveautomation.com/u/Asjal_Ahmad)\
**Post date:** [June 2, 2026, 8:03pm UTC](https://forum.inductiveautomation.com/t/twilio-whatsapp-alarm-notifications-acknowledgement/115795/8 "2026-06-02T20:03:20Z")

</div>

Got it working! Posting the full solution here in case anyone else runs into this.

Turns out there were two separate issues all stacked on top of each other.

First, the webhook path for WhatsApp is different from SMS. I had been using /system/twilio (which is the SMS path) but WhatsApp needs /data/twilio/whatsapp. That has to be set as the inbound webhook URL on your WhatsApp Sender in Twilio.

Second, and this is the big one I didn't understand at first, WhatsApp is a two-step flow. The template message that goes out first is just the invitation. You reply to it with anything to open the 24-hour free-form window, and then Ignition sends a second message with the actual alarm details and ACK code. You reply to that second message with the code to acknowledge. I had been trying to reply to the template with the code from the audit log and wondering why nothing happened.

Thanks to Dutch for pointing me toward the right webhook path and explaining the two-step flow, that really unblocked things.
