How to add WhatsApp to Ignition (SCADA/MES)
Short answer
Ignition has no native WhatsApp notification type, but its alarm notification pipelines can run a Jython script step that calls the WhatsApp Business Cloud API or a BSP over HTTPS. Replies come back through a small Web Dev module endpoint or an external relay that writes to tags or SQL.
Plants running Ignition usually already page people by email, SMS or voice through alarm notification profiles. The problem is that supervisors, maintenance leads and off-shift engineers live in WhatsApp, and an SMTP alert that lands in a crowded inbox gets read late. Teams want the alarm, the line and the last known value in the thread they actually watch.
The second pull is the reverse direction. A technician who gets an alarm wants to answer from the same chat: acknowledge, give a downtime reason, or say they are on the way. In Ignition that answer needs to become an alarm acknowledgement, a tag write, or a row in a downtime table, not just a chat message nobody reconciles.
Ignition is also a platform where the Gateway is often on a plant network with limited outbound access. So the design question is less about the WhatsApp API itself and more about where the outbound call is made, who is allowed to reach the internet, and how inbound webhooks reach a Gateway that is not publicly exposed.
What teams use it for
Critical alarm paging with context
A high-priority alarm on a press, furnace or compressor sends a templated message with area, source path, value and setpoint to the on-call group, replacing a bare SMS.
Downtime reason capture
When a line state tag drops to stopped for longer than a threshold, the operator or lead gets a quick-reply message listing reason codes, and the answer is stored against the downtime event.
Acknowledge and escalate by reply
Replying ACK to an alarm message acknowledges the alarm event in Ignition and stops the escalation timer in the pipeline, with the replier recorded.
Shift handover summary
At shift end a Gateway scheduled script sends a summary of OEE, open alarms and scrap counts from the historian to the incoming supervisor.
Quality hold alerts
A failed in-process check written to a SQL quality table triggers a message to the quality engineer with lot, station and measured value.
Contractor and supplier call-outs
External service technicians who are not in your directory get a templated call-out for a named asset, and their reply is logged as a maintenance note.
Inductive Automation Ignition (MES/SCADA) integration surface
- Alarm notification pipelines with a Script step: Jython on the Gateway can call system.net.httpClient (8.1 and later) or java.net classes to POST to a WhatsApp endpoint; exact script functions vary by Ignition version.
- Alarm journal and system.alarm functions for querying and acknowledging alarm events by ID, which is how a reply maps back to an alarm.
- Web Dev module (separately licensed) exposing doPost and doGet resources on the Gateway, usable as a webhook receiver for inbound messages.
- Gateway Tag and SQL access (system.tag.writeBlocking, system.db.runNamedQuery) for storing replies, reason codes and message audit rows.
- Gateway Network and a DMZ or edge Gateway pattern, useful when the plant Gateway cannot accept inbound traffic from the internet.
How it works
- 1
Pick the WhatsApp route
Use the WhatsApp Business Platform Cloud API directly or a business solution provider. Register a business number, get templates approved for outbound alerts, and confirm opt-in for every recipient.
- 2
Decide where the outbound call runs
Either call the API from the plant Gateway through an approved proxy, or have the Gateway post to an internal relay service that holds the access token and talks to WhatsApp. The relay keeps tokens out of Jython scripts.
- 3
Add a Script step to the alarm pipeline
In the Designer, add the step after your delay and escalation blocks. Pass the alarm event ID, display path, priority and value to a project library function that formats the template parameters.
- 4
Build the inbound path
Expose a Web Dev doPost endpoint behind a reverse proxy, or have the relay poll a queue. Verify the webhook signature, map the sender number to a user, and parse the quick-reply payload.
- 5
Map replies to actions
An ACK reply calls the alarm acknowledge function with the alarm ID, a reason code reply writes a row through a Named Query, and anything free-text goes to a notes table for review.
- 6
Log every message
Write outbound and inbound messages to a SQL audit table with alarm ID, template name, recipient, delivery status and timestamp, so an auditor can see who was told what.
Example flows
Compressor high-temperature escalation
Trigger: A high-high alarm on a compressor discharge temperature tag becomes active.
- The pipeline waits 60 seconds in case the alarm clears.
- A Script step sends a template to the maintenance on-call number with asset, value and setpoint.
- If no ACK reply arrives in 10 minutes, a second step messages the maintenance lead.
- An ACK reply hits the endpoint, which acknowledges the alarm event.
Result: The alarm is acknowledged by a named person from WhatsApp and the escalation stops.
Line stop reason by reply
Trigger: A line status tag stays in stopped state for more than five minutes.
- A gateway tag change script inserts a downtime event row.
- A message with numbered reason codes goes to the line lead.
- The lead replies with a number; the endpoint validates it against the reason code table.
- A Named Query updates the downtime event with the code and replier.
Result: Downtime events carry a reason without anyone opening a client.
Keeping data on-prem
Ignition itself is usually on-prem and that is fine, because WhatsApp is the only cloud dependency. Keep the access token and webhook secret in a relay or secrets store rather than in tag values or project scripts, and let only that relay reach the internet. For inbound traffic, publish the relay, not the Gateway, and have it forward over a one-way connection or queue into the plant network. Do not put process data in message bodies by default: send the asset name and alarm text, and let the recipient open Perspective over VPN for detail. If a language model is added to summarise alarms or interpret replies, run an open-weight model locally so tag values and free-text never leave the site.
Security checklist
- Treat the sender phone number as an identifier, not authentication. Map numbers to named users and restrict which actions a reply may trigger.
- Never allow a WhatsApp reply to write setpoints or control tags. Limit replies to acknowledge, reason codes and notes.
- Verify the webhook signature on every inbound call and reject anything unsigned.
- Store tokens outside the Gateway project export, which tends to be copied to laptops and source control.
- Keep an immutable audit table of messages and the resulting alarm or SQL change.
Ways to get it done
Generic alert gateway with an HTTP-to-WhatsApp bridge
Effort: Days, plus template approval time with the provider.
Teams that already use a notification platform and only want a Script step to call it.
Build in-house with the Cloud API, a small relay and Web Dev endpoint
Effort: Two to four weeks including security review and audit tables.
Plants with a controls engineer comfortable in Jython and an IT group that can host a relay.
Partner build with reply handling and optional local language understanding
Effort: Several weeks, scoped per site; Netray can deliver this with an Ignition integrator.
Sites that want free-text replies understood and routed, on-prem models, and a managed rollout.
Pitfalls
- !Business-initiated messages outside the 24-hour window need approved templates, so a free-form alarm text will be rejected.
- !Alarm floods will hit WhatsApp rate limits and annoy recipients. Use pipeline delays, shelving and a summary template for bursts.
- !Jython 2.7 scripts on the Gateway are not a good place for retries and queues; a failed HTTP call can silently drop the alert.
- !Group chats are not supported for business-initiated sending the way people expect, so plan on individual recipients or a different channel for team broadcast.
- !Forgetting opt-in records causes number blocks and quality rating drops.
Frequently asked questions
Does Ignition have a built-in WhatsApp notification?
No. Built-in notification types cover email, SMS and voice through profiles, and third-party modules vary. For WhatsApp you normally add a Script step in an alarm pipeline that calls the WhatsApp Business Cloud API or a provider, and handle replies separately.
Can a WhatsApp reply acknowledge an alarm?
Yes, if you build the inbound path. A webhook receives the reply, maps the sender to a user and the message to an alarm event ID, then calls the Gateway alarm acknowledge function. Keep the allowed actions narrow and log each one.
Do I need the Web Dev module?
Not strictly. Web Dev is a convenient way to host a webhook on the Gateway, but many sites prefer an external relay that validates the webhook and then writes to SQL or calls the Gateway, so the Gateway is never exposed to the internet.
Is it safe to send tag values over WhatsApp?
For most alarms, asset names and short values are acceptable, but regulated or export-controlled sites should keep process detail out of messages and send a link or reference instead. Decide this with your security team before writing templates.
Can this work without internet on the Gateway?
Only through a relay in a DMZ that has outbound access. The Gateway posts to the relay on the internal network and the relay talks to WhatsApp. A fully air-gapped plant cannot use WhatsApp and should use an on-site messaging channel instead.
Want WhatsApp working on your Inductive Automation Ignition (MES/SCADA)?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment