Push notify your users when support replies

Push, not just email

When your support team replies to a ticket, AppGram emails the customer by default. If you ship a mobile or desktop app, a native push notification lands faster and gets opened more often. This guide walks through wiring AppGram's support_ticket_reply webhook into your own push pipeline.

The flow

1. Customer opens a support ticket from your app. Your app already has their user_id and a registered push device token.
2. Your support agent replies inside AppGram.
3. AppGram POSTs a support_ticket_reply event to your webhook endpoint.
4. Your backend verifies the signature, looks up the customer's device tokens, and sends a push via APNs / FCM / Expo.
5. The push deep-links the customer back into the ticket inside your app.

Step 1 — Identify the customer in AppGram

When you open a support ticket on the customer's behalf (or accept one from your app), include a stable customer_id in the ticket metadata. That id flows through to the webhook payload as data.metadata.customer_id.

If you accept tickets only by email, you can also look the customer up by their email address — both customer_email and customer_name are included in support webhook payloads.

Step 2 — Create the webhook

1. Open your project → Developer → Webhooks → New webhook.
2. Endpoint URL: https://api.yourapp.com/webhooks/appgram/support-reply.
3. Subscribe to Support → Ticket reply. You can also include Ticket created and Ticket closed if you want to notify on those.
4. Save and copy the signing secret.

Step 3 — Handle the event

// Node/Express handler
app.post('/webhooks/appgram/support-reply', express.raw({ type: 'application/json' }), async (req, res) => {
  if (!verifySignature(req)) return res.status(401).end();

  const event = JSON.parse(req.body);
  if (event.event !== 'support_ticket_reply') return res.status(200).end();

  const { customer_id, customer_email, ticket_id, reply_preview } = event.data.metadata;

  const devices = await db.devices.findByUser({ customer_id, customer_email });
  await Promise.all(
    devices.map(d => push.send(d.token, {
      title: 'New reply from support',
      body: reply_preview,
      data: { deeplink: `yourapp://support/${ticket_id}` },
    })),
  );

  res.status(200).end();
});

Step 4 — Mute the email (optional)

If push is your primary channel and email is now redundant, you can disable the support-reply email in Settings → Email customization by clearing the subject and intro and toggling the type off, or have the customer opt out via their notification preferences page.

Heads-up

• Push is best-effort and not guaranteed — don't rely on it as your sole channel for critical replies. Keep email as a fallback for users who haven't installed the app.
• If your push service is down, return a 5xx from the webhook so AppGram retries with backoff.
• Truncate reply_preview for iOS/Android — both platforms cap notification body length around 178 characters.
• Always look up device tokens fresh — stale tokens silently fail at APNs/FCM and waste delivery attempts.