How to Send a Zendesk Urgent-Ticket Alert to a Shared Phone Room

To send one selected Zendesk urgent-ticket event to a shared group of phones, connect a Zendesk Support trigger to a small HTTPS relay, verify Zendesk’s webhook signature, accept only the expected account, webhook, and event marker, then send fixed copy to a PingRoom incoming webhook. Use a stable key based on the account, webhook, ticket, and created-event marker so retries do not become duplicate Pings.

This is a webhook recipe, not a native Zendesk integration. The destination Room’s owner needs PingRoom Pro. You also need permission to create Zendesk webhooks and triggers, plus a server-side relay with durable duplicate storage.

Start with Zendesk’s own phone notifications

Zendesk’s Support mobile app can already notify agents about all new tickets, followed tickets, assigned tickets, and tickets assigned to selected groups. Agents can also choose a notification schedule. If everyone who needs the alert is already an appropriate Zendesk agent, configure those mobile notification preferences first.

PingRoom should carry the attention signal, not the support record. This guide never copies the requester, subject, comment, organization, ticket URL, or other customer data into the Room.

Decide exactly what deserves the signal

Use one narrow trigger: a ticket is created with the priority already set to Urgent. Do not send every ticket update.

The Room receives fixed copy:

Zendesk urgent ticket created

One selected urgent support ticket needs attention in Zendesk.

That message tells the group where to look without putting the case on a lock screen. It does not say who owns the ticket, whether anyone has responded, whether the request is valid, or whether an SLA has been met.

Create the private Room and relay

Create a private Room for the stable group that needs this signal. In the browser app, open Settings → Connections → From another app, add an incoming webhook, and store the complete secret URL as PINGROOM_WEBHOOK_URL in the relay’s secret store.

The incoming-webhook walkthrough covers the Room-side setup. The webhook reference documents the current payload, cooldown, idempotency, and error behavior.

Zendesk points to your relay, not directly to PingRoom. The relay gives you a place to verify the sender, reject the wrong webhook, discard customer data, and handle retries with one stable PingRoom idempotency key.

Store these values server-side:

• ZENDESK_SIGNING_SECRET: the secret shown on the completed Zendesk webhook;
• ZENDESK_ACCOUNT_ID: the expected account header;
• ZENDESK_WEBHOOK_ID: the one webhook allowed to create this signal;
• ZENDESK_EVENT_MARKER: urgent_ticket_created;
• PINGROOM_WEBHOOK_URL: the complete secret PingRoom incoming-webhook URL.

Configure the Zendesk webhook and trigger

In Zendesk Admin Center, open Apps and integrations → Webhooks → Webhooks and create a trigger-connected webhook. Use your relay’s HTTPS endpoint, POST, and JSON. Zendesk’s current webhook setup guide explains the admin permission, authentication, test, retry, and activity-log controls.

After the webhook exists, reveal its signing secret and copy it into the relay’s secret store. Do not put it in the trigger body, browser code, logs, or source control.

Create a Support trigger with both conditions under Meet all of the following conditions:

1. Ticket → Is → Created
2. Ticket → Priority → Is → Urgent

Add Notify by → Active webhook, select the webhook, and use this complete JSON body:

{
  "event": "urgent_ticket_created",
  "ticket_id": "{{ticket.id}}"
}

Zendesk’s trigger guide says ticket triggers evaluate after a ticket is created or updated, and only apply their actions when the configured conditions match. The condition and action reference documents Urgent priority and the active-webhook action.

The trigger body deliberately contains only a fixed marker and numeric ticket identity. The relay uses that identity for replay control, then discards it before creating the Ping.

Verify the raw body before reading the JSON

Zendesk includes the signature and timestamp in X-Zendesk-Webhook-Signature and X-Zendesk-Webhook-Signature-Timestamp. Its verification guide defines the digest as Base64-encoded HMAC-SHA256 over the timestamp followed by the untouched body.

Read the raw body first. Reject an old or far-future timestamp, compute the signature with the stored secret, and compare it in constant time. Then require the expected account ID, webhook ID, invocation ID shape, event marker, and numeric ticket ID.

import { createHash, createHmac, timingSafeEqual } from "node:crypto";

function validSignature({ body, signature, timestamp, secret, now }) {
  const sentAt = Date.parse(timestamp ?? "");
  if (!Number.isFinite(sentAt) || Math.abs(now - sentAt) > 5 * 60 * 1000) {
    return false;
  }

  const expected = createHmac("sha256", secret)
    .update(timestamp + body, "utf8")
    .digest("base64");
  const left = Buffer.from(expected);
  const right = Buffer.from(signature ?? "");
  return left.length === right.length && timingSafeEqual(left, right);
}

function eventKey({ accountId, webhookId, ticketId, eventMarker }) {
  const source = [accountId, webhookId, ticketId, eventMarker].join(":");
  return `zendesk-urgent:${createHash("sha256").update(source).digest("hex")}`;
}

Zendesk webhooks have separate account, webhook, and invocation headers. Use the account and webhook IDs as an allowlist. Keep the invocation ID in request logs with an appropriate retention policy so an admin can match a relay request to Zendesk’s activity record, but derive the Ping’s replay key from the selected ticket-created event. That also covers a duplicate action that arrives under another invocation ID.

Pingo the Pigeon, PingRoom’s fictional Chief Marketing Officer, is watching the duplicate token stop at the gate. He cannot read a ticket, access a private Room, or send a Ping; the support team chose the trigger and the relay enforces it.

Queue one fixed Ping

After verification, parse exactly two fields: event and ticket_id. Reject unexpected fields rather than accidentally accepting a later trigger body that includes a subject or requester. Insert the stable key into durable duplicate storage before acknowledging the request.

The queue job needs only that key. It should not contain the ticket ID or webhook body. One consumer sends the fixed message and reuses the same key as PingRoom’s Idempotency-Key:

await fetch(env.PINGROOM_WEBHOOK_URL, {
  method: "POST",
  redirect: "manual",
  headers: {
    "Content-Type": "application/json",
    "Idempotency-Key": job.eventKey,
  },
  body: JSON.stringify({
    action: null,
    title: "Zendesk urgent ticket created",
    message: "One selected urgent support ticket needs attention in Zendesk.",
  }),
});

Treat redirects, throttles, and other non-success responses as retryable queue failures. Retry the identical body with the identical idempotency key. Do not invent a new key for every attempt.

Zendesk notes that webhook jobs run independently, are not guaranteed to execute in order, and may be retried after selected failures. This recipe does not use arrival order as ticket truth. Anyone handling the case must open Zendesk and follow the team’s normal assignment and escalation process.

Test the boundary with disposable data

Before enabling the trigger for normal work, use a harmless test ticket and a test Room:

1. A correctly signed request from the selected account and webhook queues one job.
2. Replaying the same created-ticket event queues no second job, even with another invocation ID.
3. Another account, webhook, event marker, or nonnumeric ticket identity creates no Ping.
4. A missing, incorrect, stale, or future-dated signature is rejected.
5. Malformed JSON, extra fields, an oversized body, and the wrong content type are rejected.
6. The queue consumer sends only the fixed title and message.
7. A PingRoom redirect, throttle, or other non-success remains a retryable failure.
8. A locked test phone shows no requester, subject, comment, organization, ticket URL, or other case details.

For this article, the exact dependency-free receiver and consumer passed 14 controlled boundaries with Zendesk-shaped requests, real HMAC signatures, an idempotent in-memory queue, and a local mock of PingRoom’s documented incoming-webhook contract. One unique mock signal was queued and delivered. No live Zendesk account, public relay, PingRoom Room, phone, or customer data was used.

Keep the alert smaller than the support workflow

This Room is not the ticket queue. A Ping does not assign the case, acknowledge ownership, start an SLA clock, confirm a reply, or prove that every recipient saw the notification. Device permissions, connectivity, Focus modes, Room settings, and operating-system behavior can affect display.

Zendesk documents that webhook delivery is best effort and may be delayed. PingRoom adds another delivery path, not a guarantee. For emergency paging or contractual escalation, keep the approved on-call system and escalation policy authoritative.

If one deliberately selected urgent-ticket event deserves a separate shared signal, create the private Room, deploy the relay with durable duplicate storage, and test one disposable ticket before connecting normal support work.

Zendesk is a trademark of Zendesk, Inc. PingRoom is not affiliated with or endorsed by Zendesk.