NexTool Solutions

WhatsApp is the channel your user opens dozens of times a day - and GLPI, out of the box, only knows how to speak over email. The NexTool WhatsApp Bot module connects GLPI to the Evolution API (open source, Baileys protocol) and delivers ticket notifications straight to WhatsApp, with a queue that reprocesses failures and a connection on your own infrastructure. Sustaining service desks taught us that the right channel changes the response rate for approvals and satisfaction surveys - but the integration has configuration traps this guide shows under the hood.

The problem

GLPI notifies through transactional email using the queuednotification queue. It works, but corporate email lands in spam, the end user does not live in the webmail, and the manager who needs to approve a ticket only finds out when someone calls chasing it. The day-to-day outcome is approvals stuck for hours, satisfaction surveys with a response rate near zero and a support team spending time on manual chasing. Swapping email for a channel people actually read solves most of that - and in Brazil that channel is WhatsApp.

The commercial route (the official WhatsApp Business API) is expensive, depends on Meta approving templates and ties you to an external contract. For those already running their own infrastructure, the Evolution API is the self-hosted alternative, and WhatsApp Bot connects it to GLPI using the native notification infrastructure - no hacks in the core.

How WhatsApp Bot works

The module registers its own notification mode by reusing GLPI's SMS channel (Notification_NotificationTemplate::registerMode(MODE_SMS)). When a ticket event fires, GLPI resolves the recipient, the module fetches the number, builds the message and sends it via the Evolution API - transparent to the operator.

• Its own per-event notifications - at install, the module creates nine dedicated WhatsApp notifications (New Ticket, New Follow-up, Ticket Solved, Satisfaction Survey, Approval Request, Approval Response and the three password ones), each with its own recipients. Creation is idempotent by name: if you edit the text in the GLPI UI, a reinstall preserves your edit.
• Queue with automatic retry - a message that fails due to connection instability enters the queue table and is reprocessed in batches of up to 50 every 1 minute, with a maximum of 3 attempts before being marked failed. Nothing disappears silently: the error reason is stored.
• Health check every 5 minutes - a cron polls the real connection state on the Evolution API and updates the status in the panel, so you learn WhatsApp went down before the user complains.
• QR Code inside GLPI - the sender number is connected by scanning the QR generated on the Connectors tab, without leaving the environment.
• Self-hosted or managed - point to your own Evolution API (URL + API Key) or, in a licensed environment, use the instance managed by NexTool.

The recipient number comes from the GLPI user's Mobile phone field (glpi_users.mobile), normalized automatically: the module strips formatting, validates the length (10 to 15 digits) and prefixes the 55 country code when a Brazilian number arrives without it. Whoever has no mobile on file simply does not receive it - the send is silent, it does not raise an error.

WhatsApp Bot vs native GLPI notification

How to enable it

1. Install NexTool on your GLPI and go to Setup > NexTool > Modules.
2. Enable the WhatsApp Bot module and click Configure.
3. On the Connectors tab, enter your Evolution API URL and API Key and generate the QR Code to connect the sender number.
4. In Administration > Users, fill the Mobile phone field of the recipients (country code+area+number, e.g. 5511999998888).
5. Confirm GLPI's external cron is running - the module's CronTasks are MODE_EXTERNAL and do not fire on web hits.

# The module's CronTasks (healthcheck 5min, queue 1min) are MODE_EXTERNAL.
# On GLPI 11 the trigger is front/cron.php (there is no glpi:cron console):
* * * * * www-data /usr/bin/php /var/www/html/front/cron.php >/dev/null 2>&1

# The Evolution API receives the send at this endpoint (the module handles it):
#   POST {URL}/message/sendText/{instance}
#   header: apikey: ...your_api_key...
#   body:   { "number": "5511999998888", "text": "..." }

Delivery diagnosis straight in the database

When a client says "WhatsApp did not arrive", the answer is almost always in the queue table. Two queries handle the triage:

-- Queue overview: what is stuck and how many attempts it had
SELECT status, COUNT(*) AS total, MAX(attempts) AS max_attempts
FROM glpi_plugin_nextool_whatsappbot_queue
GROUP BY status;

-- Latest failures with the reason returned by the Evolution API
SELECT id, phone_number, attempts, last_error, created_at
FROM glpi_plugin_nextool_whatsappbot_queue
WHERE status = 'failed'
ORDER BY created_at DESC
LIMIT 20;

The most common error we read in last_error is not a module bug: it is a badly formatted number or a downed instance connection. That is why the health check exists - if the panel status shows disconnected, the QR expired and needs to be rescanned.

The trap only operators know

Two gotchas break nearly every first rollout. First: the WhatsApp Bot channel travels over GLPI's SMS mode. That means, for the user to receive it, "follow by SMS" must be active on the notification - many people look for a mode called "WhatsApp" on the notifications screen and cannot find it, because it shows up as SMS. Second: GLPI appends the default email signature ("-- " and the footer) to the template body, and on WhatsApp that becomes visual noise; the module strips that block on send, but if you build your own template avoid dumping email-signature variables into it. And remember: since the number comes from glpi_users.mobile, a wrong mobile entry is the number-one cause of "I did not get it" - we normalize the country code, but we cannot guess a swapped digit.

Who it is for (and when not to use it)

WhatsApp Bot shines where the end user does not follow email: retail, healthcare, education, services and any service desk that serves an external audience. It is also excellent for approvals by managers who rarely log into GLPI. When not to use it: if your operation is 100% internal, with technicians who live logged into GLPI, an in-app notification bell is a better fit and does not depend on a WhatsApp instance. And if company policy forbids WhatsApp for work communication, respect it - the right channel is the one the team can actually use.

Compatibility

• GLPI: 10.0+ and 11.0+
• Plan: FREE
• Plugin: NexTool 4.2.1+
• Prerequisite: Evolution API installed and reachable by the GLPI server

Next step

WhatsApp Bot is part of NexTool. Need help standing up the Evolution API or tuning which events to notify over WhatsApp? Talk to the team.

This content was produced with the help of artificial intelligence and reviewed by the Nextool Solutions team.