Resolving Ignition Twilio SMS and WhatsApp Send Errors

On this gateway, system.twilio.getAccounts() returned the configured account from the Designer Script Console. Every call to sendSms, sendFreeformWhatsApp and sendWhatsAppTemplate still failed with a trace beginning at jdk.proxy2/jdk.proxy2.$Proxy83.sendSms(Unknown Source). That frame belongs to the Designer-side RPC proxy and says nothing about the cause. Each failure was a Twilio API rejection passed back through the gateway. Five separate faults sat behind the same proxy frame:

• SMS destination number format
• WhatsApp sender identity
• Messaging Service SID
• Template approval
• The alarm contact type

Fix them in the order below. Each step ends with the check that proves it before you move to the next.

Where does a Script Console Twilio call actually execute?

A script typed into the Designer Script Console does not contact Twilio. The Designer resolves system.twilio.* to a scripting module. That module forwards the call over the Designer-to-gateway RPC channel. The gateway RPC handler (TwilioRpcImpl) builds the request and sends it to the Twilio REST API using the Account SID and auth token stored in the gateway's Twilio account resource.

When Twilio rejects the request, the gateway throws a TwilioAccountException and serializes it back through the RPC channel. The Designer proxy method does not declare that exception type. Java therefore wraps it in java.lang.reflect.UndeclaredThrowableException, and the console shows the proxy frame first. The actual reason sits several Caused by: lines down, inside a ProtoWrappedException. The same exception also appears in the gateway log.

Hop	Component	What fails here	Where to read it
1	Designer Script Console (Jython)	Argument evaluation, e.g. an unquoted account name raises NameError: name '...' is not defined before any call is made	Console output
2	Designer → gateway RPC proxy ($Proxy83)	Nothing on its own. It wraps whatever the gateway threw.	Console, last Caused by: block
3	Gateway RPC handler (TwilioRpcImpl)	Logs WARN Handler for RPC call threw an exception	Gateway log
4	Gateway → Twilio REST API	Twilio rejects the request; the text is carried in TwilioAccountException	Gateway log; Twilio Console error logs
5	Twilio → SMS carrier / WhatsApp	Twilio accepted the request but delivery failed. Ignition shows no error.	Twilio Console, Monitor → Logs → Messaging and Logs → Errors → Error logs

The Designer was also logged as not being in read/write mode. Switching it to read/write produced the identical error, so that is not the fault for these calls.

1. Run the failing call once in the Script Console.
2. In the console output, scroll to the innermost Caused by: and read the text after TwilioAccountException:.
3. In the gateway log, find the WARN entry Handler for RPC call threw an exception with the matching timestamp. Copy only that stack trace; a full log bundle is too large to be useful.
4. Set the loggers twilio.RpcHandler and twilio.ConnectedTwilioAccount to TRACE for the rest of commissioning.

Exception text from gateway	Hop	Cause	Section
'To' number cannot be a Short Code	4	Destination number is missing its country code	SMS number format
Twilio could not find a Channel with the specified From address (Twilio 63007)	4	The From number is not a WhatsApp sender	WhatsApp From address
The Messaging Service Sid ... is invalid.	4	The wrong Twilio identifier was passed as the Messaging Service SID	Messaging Service SID
Twilio 63016, outside the allowed window	5	Freeform message sent with no session open, or template not approved for business-initiated use	Template approval / session window
No error, no delivery	5	Asynchronous rejection by Twilio	Twilio Console Monitor logs

Check: every failed call maps to exactly one gateway WARN with a readable Twilio message. Classify each failure with the table above before changing any configuration.

Is the gateway's Twilio account resource authenticated and Active?

Every send uses the gateway Twilio account resource. The Account SID in that resource identifies one Twilio account or subaccount. Phone numbers, senders and Messaging Services all belong to that SID. A number that lives under a different subaccount is invisible to this gateway.

Pass the account name as a quoted string, for example 'MyAccount'. An unquoted name is evaluated as a Python variable and raises NameError before the RPC call is made. A quoted string that does not match any configured account still reaches the gateway and fails there.

On this system the auth token was stored as a referenced secret. After a trial reset, and on initial gateway boot, the account sometimes showed a faulted status that pointed to authentication. This happened even though the credentials were unchanged. The workaround: open the account, edit a harmless field such as the description, and save. That forces a reconnect, and the status returns to Active.

There is a second trial-related effect. A Designer launched after the gateway trial has already expired did not show the trial-expired notice. A Designer that was already open when the trial expired did show it. Reset the trial before testing, not in the middle of a test.

1. Confirm the Account SID in the gateway resource belongs to the account or subaccount that owns your SMS number and WhatsApp sender.
2. If the status is faulted but the credentials are correct, edit the description and save.
3. Run system.twilio.getAccounts() and system.twilio.getPhoneNumbers('MyAccount').

Check: the account status shows Active, and getPhoneNumbers returns at least the SMS number. An empty result means the gateway is not reaching the Twilio account it should.

How must the SMS destination number be written?

The first real error from the gateway was:

TwilioAccountException: 'To' number cannot be a Short Code: +618562XXXX

The destination was a North American number. It was entered as + followed by the ten-digit national number, with no country code. Twilio reads the digits after + as country code plus subscriber number. Without the leading 1, the first national digits become the country code. The remaining digits are too short to be a subscriber number, so Twilio classifies the destination as a short code and refuses it.

Entered To	How Twilio parses it	Result
+ + 10-digit national number	First national digits become the country code; remainder too short	Short Code rejection
1 + 10-digit national number	Country code 1 + 10-digit NANP number	SMS sent
+1 + 10-digit national number	E.164 form, country code 1	Standard E.164; valid for Twilio

On this installation, replacing the + with 1 fixed the problem immediately. Apply the same rule to every roster contact that sends SMS: always include the country code.

Check: sendSms returns without an exception, the handset receives the text, and Twilio Console → Monitor → Logs → Messaging shows the outbound message as delivered.

Which number can Twilio accept as the WhatsApp From address?

With the To number corrected, sendFreeformWhatsApp still failed with:

TwilioAccountException: Twilio could not find a Channel with the specified From address

This is Twilio error 63007. The module adds the prefix whatsapp: to both the To and From numbers before calling the API. Pass plain digits in the same country-code format used for SMS; do not add the prefix yourself. Twilio then looks for a WhatsApp channel registered to the From number.

An ordinary SMS number has no WhatsApp channel, so the lookup fails. Tests in the Script Console confirmed this: using the SMS From number with the WhatsApp freeform function returns an error. The From number must be the number registered under Messaging → Senders → WhatsApp senders.

A sender that is registered but still waiting for Meta approval also produced vague failures. Sending before Meta had approved the sender and templates was the source of much of the early confusion. Wait until the sender shows as approved in Twilio before testing from Ignition.

1. In the Twilio Console, open Messaging → Senders → WhatsApp senders and note the sender number and its approval state.
2. Pass that number, with its country code, as the From argument.
3. Keep the SMS number for SMS profiles only.

Check: the 63007 error no longer appears in the gateway log. A remaining error at this point comes from window or template rules, covered below, not from the channel lookup.

Which Messaging Service SID does sendWhatsAppTemplate require?

Template sends failed on every attempt with:

TwilioAccountException: The Messaging Service Sid ... is invalid.

The value supplied had been taken from the WhatsApp sender pages. Twilio exposes several identifiers for WhatsApp, and only one of them is valid in this argument. The Messaging Service SID starts with MG.

Twilio identifier	Where it appears	Use in Ignition
Account SID	Account dashboard	Gateway Twilio account resource
Messaging Service SID (MG...)	Develop → Explore products → Messaging → Messaging → Services	sendWhatsAppTemplate argument; the WhatsApp Service SID field in the notification profile
Content/template SID (HX...)	Approved content template	sendWhatsAppTemplate template argument
WhatsApp Business Account ID, Meta Business Manager ID, sender SIDs	Messaging → Senders → WhatsApp senders; Meta	Not used for the Messaging Service SID field

1. In the Twilio Console left navigation, open Develop → Explore products → Messaging.
2. Select Messaging → Services and copy the SID of your service (MG...).
3. Open that service and select Sender Pool. Confirm it contains a sender of type WhatsApp, and that the sender is the same number you use as From.
4. Enter the MG SID in both the script and the WhatsApp Notification Profile.

The call that worked on this system had this form:

params = ['Test4you', 'BetaWhatsApp']
system.twilio.sendWhatsAppTemplate('MyAccount', '1##########', 'MG################################', 'HX................................', params)

Arguments, in order: gateway account name, destination number with country code, Messaging Service SID, content template SID, and a list of template parameters.

The WhatsApp Notification Profile status indicator does not validate this field. The status only reflects the linked Twilio account, so any string in the WhatsApp Service SID field still shows a green Active status. Do not use that indicator as evidence that the SID is correct.

Check: the template call returns with no invalid exception in the gateway log. The TRACE output of twilio.RpcHandler shows the request leaving the gateway.

Why does a template return 63016 when the sender is approved?

With the correct MG SID, Ignition raised no error, but nothing arrived. The Twilio Console showed:

63016 - Failed to send freeform message because you are outside the allowed window. If you are using WhatsApp, please use a Message Template.

The same failure occurred with several templates and several recipients. As soon as a recipient messaged the Twilio number first, both template and freeform sends succeeded. That pattern points to template approval.

Only templates approved for business-initiated use can be sent in that case. Here the WhatsApp sender was approved, but the template was not yet approved for business-initiated use. Twilio therefore handled the send like freeform content and rejected it with 63016.

Sender approval does not cover templates. Each template carries its own approval status. After the template was approved, the unchanged script delivered to recipients who had not messaged the number.

If you see 63016 on a template call and the script sends only a template, check the template's approval status in Twilio first. Do not assume a problem in the Ignition code.

Check:Twilio Monitor → Logs → Messaging must show the message as delivered, with no 63016 entry.

When will a freeform WhatsApp message be accepted?

A freeform message needs an open 24-hour session window. Only the recipient can open that window, by sending a message to the Twilio WhatsApp number. Sending a template does not open it; the window opens only when the recipient replies. This was confirmed on this installation.

After the account and sender were fixed, a freeform send outside the window returned without any Ignition error. Twilio had accepted the API request, and the rejection happened later, at hop 5. From Ignition's side this looks like a silent failure. The actual reason appears only in the Twilio Console.

Approved template (business-initiated)	No	No	None
Template not approved for business-initiated use	Effectively yes	No	63016
Freeform (sendFreeformWhatsApp)	Yes	No	63016 or apparent silent drop
Recipient replies to the Twilio number	n/a	Yes	n/a

For alarm notification, where the operator usually has not messaged the system recently, base the WhatsApp profile on an approved template. Treat freeform messages as follow-ups within an active conversation.

1. Test sendWhatsAppTemplate first; it does not depend on the window.
2. To test freeform, send a WhatsApp message from the handset to the Twilio number, then call sendFreeformWhatsApp.
3. If Ignition shows no error but nothing arrives, check Monitor → Logs → Errors → Error logs and Logs → Messaging.

Check: freeform delivers within the window, and the Twilio Messaging log shows 63016 for the same send made outside it.

Why is the WhatsApp sender missing from the Notification Block From Number list?

In the alarm pipeline, the Notification Block showed the template fields for the WhatsApp profile. However, the From Number dropdown offered only the SMS number, and the block does not accept a typed-in value. A block that sends from the SMS number fails for WhatsApp with 63007.

The dropdown is filled from the phone numbers on the Twilio account linked to the profile. That is the same list returned by the script call:

system.twilio.getPhoneNumbers('FlexAccount')

The call returned only the SMS number. In Twilio, the Active numbers list also held only that number. The WhatsApp sender number appeared only under Messaging → Senders → WhatsApp senders. It was a WhatsApp registration, not a number owned by the account. Disabling the gateway account, resetting the trial and re-enabling it did not change the list, because the number did not exist on the account.

1. In the Twilio Console, open Account Dashboard. Under My Twilio phone number, select View all numbers and check whether the WhatsApp number is listed.
2. If it is missing, a WhatsApp-only sender cannot simply be added to Active numbers. Create a new WhatsApp sender that uses a Twilio-owned number, and let WhatsApp register and approve it.
3. Add the new sender to the Sender Pool of the MG Messaging Service.
4. Reset or re-save the gateway Twilio account so it reloads the number list, then drop a new Notification Block in the Designer.

After the numbers were linked this way, every Script Console test passed.

Check: getPhoneNumbers returns the WhatsApp sender number, and that number is selectable as From Number in a new Notification Block using the WhatsApp profile.

Why does the pipeline send SMS but never attempt WhatsApp?

With the correct From number selected, triggering the pipeline produced SMS activity in the TRACE output and in the Twilio logs. For WhatsApp, there was no TRACE entry and no Twilio log entry at all. When there is no entry at hop 3, the request never left the notification system. Filtering by contact type is the cause.

A Twilio WhatsApp profile sends only to users who have a contact of type whatsapp. An SMS contact that holds the same phone number is ignored. The user on this system had only an SMS contact.

In that module beta, the user management UI could not add a whatsapp contact type, and calculated rosters did not support it. The options were to add the contact through the user API by script, or to move to the next beta release that fixes both issues.

1. Add a whatsapp contact to every roster user who should receive WhatsApp alarms. Use a number with country code.
2. Use a static roster, or confirm that your module build supports whatsapp contacts in calculated rosters.
3. Fill in the template parameters in the block. In this beta they are edited in a pop-up dialog.

The gateway notification profile test is not proof of delivery. It returned a green Evaluation Complete status with no gateway event, even while the scripts were failing. The profile status indicator is equally unreliable for the reason given in the Messaging Service SID section.

Check: when the pipeline fires, the twilio.RpcHandler TRACE output shows a WhatsApp template request for the roster user.

How do I prove an alarm reaches the WhatsApp handset end to end?

Run this sequence after every configuration change. Stop at the first failed step and return to the section for that hop.

1. The gateway Twilio account shows Active. getPhoneNumbers returns both the SMS number and the WhatsApp sender number.
2. sendSms to a number with country code delivers, and the Twilio Messaging log records it.
3. After the handset replies, sendFreeformWhatsApp delivers within the window.
4. The Notification Block lists the WhatsApp sender as From Number, and the roster user has a whatsapp contact.
5. Trigger the alarm. TRACE output from twilio.RpcHandler and twilio.ConnectedTwilioAccount shows the WhatsApp request. Twilio Monitor → Logs → Messaging shows an outbound WhatsApp message with a delivered status, and the Error logs show no 63007 or 63016 entry for that timestamp.

FAQ