This new version connects to Zender API thus let you fetch all messages you have already sent, the status (failed, successful/sent) and saves in a Mautic DB all JSONs of every API call, giving you the option to build reports.
Also it let’s you fetch the recieved answers. YES! the answers clients/users give you via WhatsApp.
Also, it saves in the leads table the last event per user regarding sent or recieved WhatsApp messages, so you can use them to create segments or events.
Hope you enjoy this new release and please, I am open to suggestions.
Next step: AI to rewrite outgoing messages (more personalization), fetch received messages and errors sending as the event happens and if someone helps me to understand how, auto answer on received messages.
Please, let me know if there is something else you would like or if you need some help configuring this or a Zender installation. We can provide with a Zender server so you don’t have to have your own or other configuration/installation/marketing services.
If still doesn’t work, let me know and I’ll send you a version through this forum… but currently I am using the same version in main, so will be sending you the same file.
Hello Renato
I know about version 1.1.2 — it works on Mautic 6.0.x, but it doesn’t support the receiving function like version 1.1.14 does.
There are already some automations that we use for our companies, so we have to stay on Mautic 5.2.x. and plugin v1.1.14
You’re right: the current “Mautic 6 compatible” plugin branch does not include inbound/receive handling. I reviewed older revisions and there are only partial / unfinished experiments, not a complete inbound implementation.
Inbound is absolutely doable, but there are two different “inbound” goals people usually mean, and the implementation depends on which one you need:
Capture inbound messages and store them in Mautic (log them, attach to the contact, keep the conversation history).
Use inbound messages to trigger automation (keyword triggers, “reply with 1/2/3”, capture data like name/email, etc.).
Zender already stores inbound messages and provides API + webhook, so the missing part is not “getting the message”, it’s how we map inbound events into Mautic in a useful way (and without duplicating Zender as a database of record).
If you share your use case, I can evaluate the best approach and see whether it makes sense to add inbound support (and in what scope). A few quick questions to understand what you actually need:
Do you need automation triggers, message logging, or both?
Is webhook delivery available in your setup, or would you prefer a polling/cron sync approach?
How do you identify the contact: phone only, or do you also rely on a custom field like id_whatsapp_in_zender?
What’s the minimum viable behavior you’d want first (e.g., “log inbound + tag contact when message contains keyword X”)?
Once I have that context, I can outline a possible implementation path and you can help validate it with testing on a live installation.
Inbound can be approached in two ways: (1) webhook-based (real-time) or (2) cron/polling (periodic sync).
Either way, the flow is: receive message → normalize sender phone (E.164) → match a Mautic contact → log/update contact fields → optionally trigger automation (tags/segments/campaign logic).
The main design choice is whether you want simple logging or automation triggers (keyword/reply-driven).
We can keep it minimal (store only “last inbound message/date” + tags) to avoid duplicating Zender as the system of record.
Again, your use case is needed so I can recommend which path fits your setup best.
I want to add a bit more context on what I mean by “use case”, because it’s the difference between “receiving messages” and “receiving messages that actually create value inside Mautic”.
A good example is another plugin I built: 7 Cats – Shopping2Mautic.
Concrete use case (very clear):
When a customer places an order in WooCommerce (or when orders are imported from Magento), the plugin pushes that event into Mautic by creating/updating the contact and enriching it with purchase intelligence.
Mautic ends up “knowing” things like: last order date, last order amount, last order status, lifetime revenue, lifetime order count, purchase frequency, last order categories, and last order items (as JSON).
With that data, you can build campaigns like:
“High LTV customers → VIP flow”
“No purchase in 60 days → winback”
“Bought from category X → cross-sell related items”
“Order status changed to completed → post-purchase automation”
Optionally, the plugin can also send WhatsApp notifications via Zender, and store each payload to a file channel for auditing.
That is a complete use case: event → data model → Mautic fields → segmentation → automation outcomes.
So for inbound WhatsApp in the Zender plugin, I’m looking for the same clarity. “Receive messages” alone is not the goal; the goal is what you want Mautic to do with those inbound messages.
In Mautic 5 we had fields (I may be slightly off on the exact names) like “last message date” and **“last message text.”**We used this in Mautic for a hotel workflow: we would send a WhatsApp message to the customer to confirm an action — for example parking or confirming some other request.
Because those values were stored as custom contact fields, we could build segments based on the message content using regular expressions. That made the scenario quite flexible: you can drive different automations depending on what the inbound message contains, and when it arrived.