Drafted with Claude Code on behalf of Geoffrey Roberts (Saddleback Church), who reviewed it and is posting it.

Churches with campuses outside the US often find that their members use WhatsApp rather than text messages. Twilio sends and receives WhatsApp through the same Messages API Rock already uses for SMS, so Rock could support WhatsApp with very little change. We tested this on Rock 19.8.1 with Twilio’s WhatsApp Sandbox:

• Incoming messages already work. Twilio posts WhatsApp messages to Rock’s existing TwilioSms.ashx webhook with the numbers prefixed whatsapp:. Rock’s person matching strips the number to digits, so the sender is matched correctly. Once a system phone number matched the WhatsApp sender, the message appeared in SMS Conversations like any text.
• Sending from Rock fails. The Twilio transport sends the WhatsApp sender with a plain recipient number, and Twilio rejects it: “Invalid From and To pair. From and To should be of the same channel.”
• The prefix can’t simply be stored on the system phone number: whatsapp:+1XXXXXXXXXX is longer than the Number field’s 20-character limit, and Twilio needs the +.

Suggested approach:

• A “WhatsApp sender” setting on a system phone number (the number itself stays plain).
• The Twilio webhook removes the whatsapp: prefix before matching, so conversations, person matching and SMS pipelines work unchanged.
• The Twilio transport adds whatsapp: to both numbers when sending from a WhatsApp sender.
• Messages sent more than 24 hours after the person last wrote must use a WhatsApp template approved by Meta (Twilio’s Content API), so communications from a WhatsApp sender would need a way to pick a template.
• Opt-outs are tracked by phone number, so a STOP over WhatsApp would also stop texts to that number (and the reverse); that may be fine, but it’s worth deciding deliberately.

We’re building this for our own campuses and would be glad to contribute it as a pull request if the core team agrees with the approach.

Geoffrey Roberts,
Saddleback Church