Sending WhatsApp Notifications from Zendesk Ticket Updates

A ticket sits in "Open" for two days, gets solved, and the customer only finds out when they happen to check their email — or never. Zendesk's own notification channel is email and in-app; WhatsApp gets read in minutes, not days. Wiring ticket-status changes into WhatsApp doesn't require a marketplace app: Zendesk's built-in triggers plus a webhook target and the TextMeFlow messages API is enough.

Step 1: Create a webhook target in Zendesk

In Zendesk Admin Center, go to Apps and integrations → Webhooks → Create webhook. Point it at a small receiver you host (an endpoint on your own server or a serverless function):

• Endpoint URL: your receiver, e.g. https://yourapp.example.com/zendesk-hook
• Request method: POST
• Authentication: use a bearer token or basic auth header — Zendesk supports both — so your receiver can reject requests that don't carry it

Zendesk webhooks fire an empty or minimal payload by default; the actual ticket data comes from the trigger you attach to it (next step), using placeholders in the request body.

Step 2: Build the trigger that calls the webhook

Under Objects and rules → Business rules → Triggers, create a trigger with a condition like "Ticket status changed to Solved" and add a "Notify webhook" action pointing at the target from step 1. Set the JSON body using Zendesk placeholders so the payload actually contains something useful:

{
  "ticket_id": "{{ticket.id}}",
  "status": "{{ticket.status}}",
  "requester_phone": "{{ticket.requester.phone}}",
  "subject": "{{ticket.title}}"
}

Make a separate trigger per status transition you care about (Solved, or Open → Pending waiting on the customer) rather than one trigger for "any update" — Zendesk fires triggers on every ticket save, including internal note edits, and you don't want a WhatsApp message for those.

Step 3: Receive the webhook and forward to WhatsApp

import express from 'express';
const app = express();
app.use(express.json());

app.post('/zendesk-hook', async (req, res) => {
  const auth = req.headers.authorization;
  if (auth !== `Bearer ${process.env.ZENDESK_WEBHOOK_SECRET}`) {
    return res.sendStatus(401);
  }

  const { status, requester_phone, subject, ticket_id } = req.body;
  if (!requester_phone) return res.sendStatus(200);

  const text = status === 'solved'
    ? `Your ticket "${subject}" (#${ticket_id}) has been resolved. Reply if you still need help.`
    : `We're waiting on your reply for ticket "${subject}" (#${ticket_id}).`;

  await fetch('https://api.textmeflow.eu/v1/messages', {
    method: 'POST',
    headers: {
      Authorization: `Bearer ${process.env.TEXTMEFLOW_TOKEN}`,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({ to: requester_phone, text }),
  });

  res.sendStatus(200);
});

The same call works from PHP or Python with any HTTP client — see the PHP, Python and Node examples if you're not on Node.

Step 4: Normalize the phone number before sending

Zendesk stores the requester's phone as whatever format they entered it in, or blank if it was never collected. TextMeFlow requires strict E.164 (+3247...) — anything else gets rejected with 400 invalid_recipient. Skip the send rather than guess when the field is empty or clearly not a phone number, and consider adding a required phone field to your Zendesk ticket form if WhatsApp notifications matter enough to build this integration in the first place.

Step 5: Keep it to status changes, not every comment

A ticket with an active back-and-forth can get a dozen comment updates in an hour. Sending a WhatsApp message for each one is a fast way to annoy the customer and trip TextMeFlow's anti-spam pacing — consecutive sends to the same number get spaced out automatically once volume looks bot-like. Reserve WhatsApp for the transitions that actually change what the customer needs to do: ticket solved, ticket needs their reply, or a new agent picked it up. Route routine comment activity to email or the Zendesk widget instead.

Agent-side notifications too

The same pattern works in the other direction: a trigger on "ticket assigned" or "SLA breach imminent" that messages the assigned agent's own WhatsApp instead of the customer's. That's internal, one-to-one traffic with no consent question attached, and it's a good first integration to test your receiver against before pointing anything at customers.

Start free on TextMeFlow — 50 messages a month, no time limit, enough to build and test a Zendesk trigger end to end before committing to a paid plan.