Building a WhatsApp notification module — Cloud API direct, no gateway lock-in. Looking for input

[semihturna]

Hi all,

 

The WhatsApp client notifications request on the feature tracker has 559 votes and is still open, so I started building a notification provider module for it.

 

What I'm aiming at is different from the options I found. Every one of them routes you through a paid gateway - Twilio, or the vendor's own service - with a fee on top of what Meta already charges. I want to remove that layer:

 

- Connects straight to Meta's WhatsApp Cloud API with your own credentials. No middleman, no markup on top of Meta's own per-message cost.

- One-time purchase, not a subscription.

- Ships with ready-made message templates for the usual WHMCS events, so you are not writing and submitting templates to Meta from scratch.

 

Before I go further I would rather ask than guess:

 

1. Are you already sending WhatsApp notifications somehow? If yes, what are you using and what annoys you about it?

2. Which events actually matter to you? I am assuming invoice created, payment received, overdue reminder, service due and domain expiry - but I would rather hear it from people running this daily.

3. Would you prefer a one-time purchase or a subscription? I am planning one-time, but tell me if that is wrong.

 

Also: if anyone is willing to test an early build on a real install, I will give you a free lifetime licence. Honest feedback is worth more to me than the sale.

 

Thanks,

Semih

[Waqas Ahmed Waseer]

Hi Semih, going direct to the Cloud API instead of through a middleman is the right call. Here are my answers from the hosting ops side.

 

1) Sending WhatsApp today and what annoys me

I haven't found anything clean. The usual options are hook scripts, email-to-message gateways, or a third-party layer in the middle. The pain points I'd want solved are:

- Template approval. Anything that goes outside the 24-hour customer-service window has to be a pre-approved template, so the module needs to handle template names, languages and variables properly.

- Category. Meta treats UTILITY (invoice due, payment received, service suspended) differently from MARKETING, and the pricing differs. Meta can also recategorise a template you submitted as UTILITY. Ready-made templates should be worded so they're clearly transactional, with no upsell text, or they'll end up in the wrong bucket.

- Delivery status. "API accepted it" doesn't mean the customer got it. I'd want the webhook statuses (sent, delivered, read, failed) stored against the client or invoice, with the failure reason visible. Otherwise you find out at suspension time that the reminder never arrived.

- Phone numbers. WHMCS phone formats are a mess, so E.164 normalisation and a sensible country-code fallback matter more than people expect.

- Opt-in. Per-client consent should be recorded, so the module can skip clients who haven't opted in.

 

2) Events that matter

For clients:

- invoice created

- payment reminders and overdue notices

- payment received

- failed card payment

- service suspended or unsuspended

- domain expiry

- ticket reply

 

For staff:

- new order

- fraud-flagged order

- high-priority ticket

- failed module commands or provisioning errors

 

I'd keep credentials and passwords out of WhatsApp entirely.

 

A question on architecture: as I understand it, WHMCS notification rules are mainly aimed at staff-side channels. How are you handling client-facing messages, with per-client recipients and opt-in? A proper Notification Provider is much better than email-pipeline hacks, because you get event rules, no parsing of rendered emails, and a cleaner failure path. I'd just like to understand how it covers the client side.

 

3) One-time vs subscription

I prefer one-time. Hosters get tired of recurring fees on small modules. Meta's API will keep changing, though, so a one-time price with an optional paid update and support period seems fair to me.

 

I'd happily try an early build if you're offering one.